Hi.

The bootstrap problems I've been having on the x86 Solaris machine,
plus the reply from maintainer Rainer Orth that his builds have
been succeeding were the impetus to investigate how 'git bisect'
works. After a bit of fumbling around, including a rebuild of
an apparently miscompiled 'git' binary, I was able to bisect
the build problems to this commit:

4899856f3f2fdefaffa0d5355d8dae034da9ec26 is the first bad commit
commit 4899856f3f2fdefaffa0d5355d8dae034da9ec26
Author: bernds <ber...@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Thu Sep 23 10:04:33 2010 +0000

        PR rtl-optimization/44374
        * basic-block.h (enum bb_flags): Add BB_MODIFIED.
        * df-core.c (df_set_bb_dirty): Set it.
        * ifcvt.c (find_memory): Remove function.
        (dead_or_predicable): Use can_move_insns_across.
        * df.h (can_move_insns_across): Declare function.
        * cfgcleanup.c (block_was_dirty): New static variable.
        (try_crossjump_bb, try_forward_edges): Test BB_MODIFIED flag rather
        than df_get_bb_dirty.
        (try_head_merge_bb): New static function.
        (try_optimize_cfg): Call it.  Call df_analyze if block_was_dirty
        is set.
        * df-problems.c: Include "target.h"
        (df_simulate_find_uses): New static function.
        (MEMREF_NORMAL, MEMREF_VOLATILE): New macros.
        (find_memory, find_memory_store): New static functions.
        (can_move_insns_across): New function.
        * Makefile.in (df-problems.o): Update dependencies.

    testsuite/
        PR rtl-optimization/44374
        * gcc.target/arm/headmerge-1.c: New test.
        * gcc.target/arm/headmerge-2.c: New test.
        * gcc.target/i386/headmerge-1.c: New test.
        * gcc.target/i386/headmerge-2.c: New test.


    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/tr...@164552 
138bc75d-0d04-0410-961f-82ee72b054a4

:040000 040000 8eba3de7802f571601cb7092cfd546609f24086f 
c8b21579e48331ae0fa528fb89a228ea94211691 M      gcc

As my last successful build was on Sep. 22, date-wise this commit seems
reasonable. Why this revision seems to trip the gcc_assert() on line 1881
of gcc/dwarf2out.c I don't know ...

     gcc_assert (REGNO (XEXP (src, 0)) == cfa.reg)

Also, I've been using my own builds of the GNU Binutils 2.20.1 release 
assembler and linker for my GCC builds, and they've always worked well.
Yesterday I tried a build using GNU 'as' and the Solaris 'ld' linker
but my build failed with the same assertion.

Here's my GCC configuration from the last successful build:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/export/home/arth/local/libexec/gcc/i386-pc-solaris2.10/4.6.0/lto-wrapper
Target: i386-pc-solaris2.10
Configured with: /home/ahaas/gnu/gcc.git/configure 
--prefix=/export/home/arth/local --enable-languages=c,c++,objc,fortran 
--disable-nls --with-gmp=/export/home/arth/local 
--with-mpfr=/export/home/arth/local --enable-checking=release 
--enable-threads=posix --with-gnu-as --with-as=/export/home/arth/local/bin/as 
--with-gnu-ld --with-ld=/export/home/arth/local/bin/ld 
--enable-libstdcxx-pch=no --enable-objc-gc --build=i386-pc-solaris2.10
Thread model: posix
gcc version 4.6.0 20100922 (experimental) (GCC)

The build issues on the sparc box were resolved once the patch to
the 'gmon-sol2.c' file made it here. Today's builds worked without
any problem.

I'd be glad to test any patch(es) that may help identify and resolve
the problem I'm seeing.

As always, thanks to all the GCC developers.

Art Haas

Reply via email to