[Bug c++/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV

[Bug c++/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43085

--- Comment #7 from Martin Jambor <jamborm at gcc dot gnu.org> 2010-10-11 17:46:00 UTC ---
I have run 'make profiledbootstrap' of today's checkout of the 4.5
branc (revision 165315) on i686 and it finished without any problems
for me.  I believe I configured it much like it is in the summary,
except that I used "yes" checking.

Can you please check whether the problem persists for you on the
current branch?  Thanks.

[Bug c++/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV

[aanisimov at inbox dot ru]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43085

--- Comment #8 from Artem Anisimov <aanisimov at inbox dot ru> 2010-10-12 12:25:10 UTC ---
(In reply to comment #7)
> I have run 'make profiledbootstrap' of today's checkout of the 4.5
> branc (revision 165315) on i686 and it finished without any problems
> for me.  I believe I configured it much like it is in the summary,
> except that I used "yes" checking.
> 
> Can you please check whether the problem persists for you on the
> current branch?  Thanks.

 Doing profiledbootstrap with r165350 gives the following error (configuration
options are the same as in the initial report):

/home/artem/testing/gcc-build/./prev-gcc/xgcc
-B/home/artem/testing/gcc-build/./prev-gcc/
-B/home/artem/testing/gcc45/i686-slackware-linux/bin/
-B/home/artem/testing/gcc45/i686-slackware-linux/bin/
-B/home/artem/testing/gcc45/i686-slackware-linux/lib/ -isystem
/home/artem/testing/gcc45/i686-slackware-linux/include -isystem
/home/artem/testing/gcc45/i686-slackware-linux/sys-include    -c
-DHAVE_CONFIG_H -g -O2 -fomit-frame-pointer -fprofile-use  -I.
-I../../gcc-current/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic  ../../gcc-current/libiberty/fibheap.c -o
fibheap.o
../../gcc-current/libiberty/fibheap.c: In function
'fibheap_replace_key_data.part.5':
../../gcc-current/libiberty/fibheap.c:486:1: error: corrupted profile info:
profile data is not flow-consistent
../../gcc-current/libiberty/fibheap.c:486:1: error: corrupted profile info:
number of executions for edge 15-11 thought to be 21911
../../gcc-current/libiberty/fibheap.c:486:1: error: corrupted profile info:
number of executions for edge 15-16 thought to be -18020
../../gcc-current/libiberty/fibheap.c:486:1: error: corrupted profile info:
number of executions for edge 17-19 thought to be -8519
../../gcc-current/libiberty/fibheap.c:486:1: error: corrupted profile info:
number of executions for edge 17-18 thought to be 15215
../../gcc-current/libiberty/fibheap.c:486:1: error: corrupted profile info:
number of executions for edge 19-20 thought to be 14201
../../gcc-current/libiberty/fibheap.c:486:1: error: corrupted profile info:
number of executions for edge 19-21 thought to be -6112
make[3]: *** [fibheap.o] Erreur 1

 I tried running compilation twice and always had this result.

[Bug c++/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV

[aanisimov at inbox dot ru]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43085

--- Comment #9 from Artem Anisimov <aanisimov at inbox dot ru> 2010-10-12 12:28:10 UTC ---
(In reply to comment #7)

 It's interesting to note that profiledbootstrap break amd64 build too, though
for different reason:

/home/artem/testing/gcc-build/./prev-gcc/xgcc
-B/home/artem/testing/gcc-build/./prev-gcc/
-B/home/artem/testing/gcc46/x86_64-slackware-linux/bin/
-B/home/artem/testing/gcc46/x86_64-slackware-linux/bin/
-B/home/artem/testing/gcc46/x86_64-slackware-linux/lib/ -isystem
/home/artem/testing/gcc46/x86_64-slackware-linux/include -isystem
/home/artem/testing/gcc46/x86_64-slackware-linux/sys-include    -c 
-DIN_GCC_FRONTEND -g -O2 -gtoggle -fprofile-generate -DIN_GCC   -W -Wall
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat  
-DHAVE_CONFIG_H -I. -I. -I../../gcc-current/gcc -I../../gcc-current/gcc/.
-I../../gcc-current/gcc/../include -I../../gcc-current/gcc/../libcpp/include 
-I../../gcc-current/gcc/../libdecnumber
-I../../gcc-current/gcc/../libdecnumber/bid -I../libdecnumber  
-I/usr/include/libelf  ../../gcc-current/gcc/c-parser.c -o c-parser.o
../../gcc-current/gcc/c-parser.c: In function 'c_parser_for_statement':
../../gcc-current/gcc/c-parser.c:4672:19: error: 'incr' may be used
uninitialized in this function [-Werror=uninitialized]
cc1: all warnings being treated as errors

  For amd64 I configured with these settings:

../gcc-current/configure --prefix=/home/artem/testing/gcc46 --enable-shared
--enable-bootstrap --enable-languages=c,c++ --enable-threads=posix
--enable-checking=release --with-system-zlib --disable-libunwind-exceptions
--enable-__cxa_atexit --enable-libssp --with-gnu-ld --with-lto --disable-nls
--verbose --with-arch=athlon64 --target=x86_64-slackware-linux
--build=x86_64-slackware-linux --host=x86_64-slackware-linux --disable-multilib
--enable-checking=release

  Doing normal (not profiled) build with these settings succeeds for me.

[Bug c++/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV

[fierevere at ya dot ru]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43085

Sylvia <fierevere at ya dot ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fierevere at ya dot ru

--- Comment #10 from Sylvia <fierevere at ya dot ru> 2010-10-13 14:30:19 UTC ---
(In reply to comment #7)
> Can you please check whether the problem persists for you on the
> current branch?  Thanks.

still the same, revision 165423 from /branches/gcc-4_5-branch


libtool: compile:  /var/tmp/gccbuild/./gcc/xgcc -shared-libgcc
-B/var/tmp/gccbuild/./gcc -nostdinc++
-L/var/tmp/gccbuild/i586-sylvia-linux/libstdc++-v3/src
-L/var/tmp/gccbuild/i586-sylvia-linux/libstdc++-v3/src/.libs
-B/usr/local/gcc-4.5/i586-sylvia-linux/bin/
-B/usr/local/gcc-4.5/i586-sylvia-linux/lib/ -isystem
/usr/local/gcc-4.5/i586-sylvia-linux/include -isystem
/usr/local/gcc-4.5/i586-sylvia-linux/sys-include
-I/var/tmp/gccbuild/i586-sylvia-linux/libstdc++-v3/include/i586-sylvia-linux
-I/var/tmp/gccbuild/i586-sylvia-linux/libstdc++-v3/include
-I/var/tmp/gcc-4.5.2pre_101013_r165423/libstdc++-v3/libsupc++
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections -O2 -pipe
-fomit-frame-pointer -march=pentium4 -mtune=core2 -msse2 -mstackrealign
-fexcess-precision=fast -D_GNU_SOURCE -c
../../../../gcc-4.5.2pre_101013_r165423/libstdc++-v3/src/pool_allocator.cc 
-fPIC -DPIC -o .libs/pool_allocator.o
In file included from
../../../../gcc-4.5.2pre_101013_r165423/libstdc++-v3/src/pool_allocator.cc:31:0:
/var/tmp/gccbuild/i586-sylvia-linux/libstdc++-v3/include/ext/pool_allocator.h:
In constructor '__gnu_cxx::__pool_alloc<_Tp>::__pool_alloc() [with _Tp =
char]':
../../../../gcc-4.5.2pre_101013_r165423/libstdc++-v3/src/pool_allocator.cc:171:18:
  instantiated from here
/var/tmp/gccbuild/i586-sylvia-linux/libstdc++-v3/include/ext/pool_allocator.h:140:30:
internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[4]: *** [pool_allocator.lo] Error 1



environment:
export CC=cc45
export CXX=c++45
AFLAGS="-O2 -pipe -fomit-frame-pointer -march=pentium4 -mtune=core2 -msse2
-mstackrealign -fexcess-precision=fast"
export CXXFLAGS_FOR_BUILD=${AFLAGS}
export CFLAGS_FOR_BUILD=${AFLAGS}
export BOOT_CFLAGS=${AFLAGS}
export LIBCFLAGS=${AFLAGS}
export LIBCXXFLAGS=${AFLAGS}
export CXXFLAGS_FOR_TARGET=${AFLAGS}
export CFLAGS_FOR_TARGET=${AFLAGS}
export CFLAGS=${AFLAGS}
export CXXFLAGS=${CFLAGS}
export JCFLAGS="-O2"
export FCFLAGS="-O2"

../${SRCDIR}/configure \
--prefix=/usr/local/gcc-4.5 \
--host=i586-sylvia-linux --build=i586-sylvia-linux --with-pkgversion=/argenta/
\
--disable-nls --with-cpu=core2 --with-arch=pentium4 \
--enable-languages=c,c++ --disable-stage1-checking --enable-checking=release \
--enable-threads --enable-tls \
--with-host-libstdcxx="/usr/local/gcc-4.5/lib/libstdc++.a /usr/lib/libm.a" \
--enable-lto --with-fpmath=sse

[Bug c++/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43085

Martin Jambor <jamborm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2010.10.13 14:37:41
     Ever Confirmed|0                           |1

--- Comment #11 from Martin Jambor <jamborm at gcc dot gnu.org> 2010-10-13 14:37:41 UTC ---
Right, I tried again and with "release" checking I get a segfault too.  I'll
examine this closer.

[Bug c++/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV

[fierevere at ya dot ru]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43085

--- Comment #12 from Sylvia <fierevere at ya dot ru> 2010-10-13 15:10:34 UTC ---
(In reply to comment #8)

Artem, did you tried to make concurrent build ( make -j2 or anything more than
-j1 ) ?

there shouldnt be any collisions when building with single task (make -j1)

Does adding "-Wcoverage-mismatch -fprofile-correction" flags help the issue?

[Bug c++/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV

[aanisimov at inbox dot ru]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43085

--- Comment #13 from Artem Anisimov <aanisimov at inbox dot ru> 2010-10-13 17:46:51 UTC ---
> Artem, did you tried to make concurrent build ( make -j2 or anything more than
> -j1 ) ?

  I know about this trick and did a -j1 build :). Anyway, thanks for pointing
this out.

> Does adding "-Wcoverage-mismatch -fprofile-correction" flags help the issue?

  Where do these go?

[Bug c++/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43085

--- Comment #14 from Martin Jambor <jamborm at gcc dot gnu.org> 2010-12-16 11:14:42 UTC ---
I've tried make profiledebootstrap with IPA-SRA disabled (directly in the code)
and it segfaulted anyway.  Will try it with disabled IPA-CP tonight.

[Bug c++/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43085

--- Comment #15 from Martin Jambor <jamborm at gcc dot gnu.org> 2010-12-21 14:35:17 UTC ---
And it fails for me even when I switch both IPA-SRA and IPA-CP off.
So at the moment I have reasons to believe the bug is not in any of my
areas of knowledge or interest.  And since there are bugs like that,
I'll leave this one to others.

[Bug c++/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV

[onur at pardus dot org.tr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43085

--- Comment #16 from Onur Küçük <onur at pardus dot org.tr> 2010-12-21 14:43:41 UTC ---
I can also reproduce the problem. It was not there with 4.5.1, came with 4.5.2.
When I force -O1 profiledbootstrap works fine, but ICE occurs with -O2.

[Bug c++/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV

[onur at pardus dot org.tr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43085

--- Comment #17 from Onur Küçük <onur at pardus dot org.tr> 2010-12-21 17:10:48 UTC ---
I see this with i686 btw, x86-64 seems ok

[Bug c++/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV

[onur at pardus dot org.tr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43085

--- Comment #18 from Onur Küçük <onur at pardus dot org.tr> 2011-02-28 09:50:51 UTC ---
I have found that reverting r167492  [1] fixes the problem for me. Of course it
brings back PR46806 but at least it should give a hint where the problem is.

Attaching the change as a patch, in case anyone is interested.


[1] http://gcc.gnu.org/viewcvs?view=revision&revision=167492

[Bug c++/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV

[onur at pardus dot org.tr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43085

--- Comment #19 from Onur Küçük <onur at pardus dot org.tr> 2011-02-28 09:51:50 UTC ---
Created attachment 23488
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23488
revert 167492 patch

[Bug c++/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV

[michael.hope at linaro dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43085

Michael Hope <michael.hope at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |michael.hope at linaro dot
                   |                            |org

--- Comment #20 from Michael Hope <michael.hope at linaro dot org> 2011-04-13 07:23:49 UTC ---
I'm seeing this problem with r172238 on i686.  See:

http://builds.linaro.org/toolchain/gcc-4.5+svn172238%5Eprofiled/logs/i686-lucid-cbuild109-scorpius-profiled/

4.6.0 is fine.

[Bug c++/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV

[fierevere at ya dot ru]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43085

--- Comment #21 from Sylvia <fierevere at ya dot ru> 2011-04-13 07:24:32 UTC ---
Sorry, this mail address it not being used anymore, this message has been sent
automatically.
Извините, этот адрес более не используется, это сообщение было отправлено
автоматически.

[Bug middle-end/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV

[uweigand at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43085

Ulrich Weigand <uweigand at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |uweigand at gcc dot gnu.org
          Component|c++                         |middle-end

--- Comment #22 from Ulrich Weigand <uweigand at gcc dot gnu.org> 2011-04-27 16:14:49 UTC ---
I've confirmed the problem with the current 4.5 branch.  Note that the problem
disappears when building with --enable-checking.

A minimal testcase showing the internal compiler error in cc1plus when built
with profile-directed feedback:

class __pool_alloc_base
{
  void _M_round_up () { }
  void _M_get_free_list () { }
  void _M_get_mutex () { }
  void _M_refill () { }
  void _M_allocate_chunk () { }
};

template <typename _Tp> class __pool_alloc : __pool_alloc_base
{
  __pool_alloc () { }
  ~__pool_alloc () { }
};

template class __pool_alloc<char>;

The crash occurs because build_new_method_call is unable to find the base_ctor
method in the __pool_alloc_base class, and then crashes when accessing a NULL
method pointer.  The pointer is not checked for NULL as that routine must be
there since it was added by the compiler itself automatically.

However, due to a mis-compilation of the add_method routine, the method vector
data structure was not actually updated.  The code in add_method does:

      bool reallocated;

      /* We only expect to add few methods in the COMPLETE_P case, so
         just make room for one more method in that case.  */
      if (complete_p)
        reallocated = VEC_reserve_exact (tree, gc, method_vec, 1);
      else
        reallocated = VEC_reserve (tree, gc, method_vec, 1);
      if (reallocated)
        CLASSTYPE_METHOD_VEC (type) = method_vec;
      if (slot == VEC_length (tree, method_vec))
        VEC_quick_push (tree, method_vec, overload);
      else
        VEC_quick_insert (tree, method_vec, slot, overload);

But due to the mis-compile, the 
  CLASSTYPE_METHOD_VEC (type) = method_vec;
line is not executed in this particular case, even though "reallocated" is set.

The vec.h header file routines inlined into add_method here are as follows:

static inline int VEC_OP (T,base,space)                                   \
     (VEC(T,base) *vec_, int alloc_ VEC_CHECK_DECL)                       \
{                                                                         \
  VEC_ASSERT (alloc_ >= 0, "space", T, base);                             \
  return vec_ ? vec_->alloc - vec_->num >= (unsigned)alloc_ : !alloc_;    \
}                                                                         \

static inline int VEC_OP (T,A,reserve)                                    \
     (VEC(T,A) **vec_, int alloc_ VEC_CHECK_DECL MEM_STAT_DECL)           \
{                                                                         \
  int extend = !VEC_OP (T,base,space) (VEC_BASE(*vec_), alloc_            \
                                       VEC_CHECK_PASS);                   \
                                                                          \
  if (extend)                                                             \
    *vec_ = (VEC(T,A) *) vec_##A##_p_reserve (*vec_, alloc_ PASS_MEM_STAT); \
                                                                          \
  return extend;                                                          \
}                                                                         \

static inline int VEC_OP (T,A,reserve_exact)                              \
     (VEC(T,A) **vec_, int alloc_ VEC_CHECK_DECL MEM_STAT_DECL)           \
{                                                                         \
  int extend = !VEC_OP (T,base,space) (VEC_BASE(*vec_), alloc_            \
                                       VEC_CHECK_PASS);                   \
                                                                          \
  if (extend)                                                             \
    *vec_ = (VEC(T,A) *) vec_##A##_p_reserve_exact (*vec_, alloc_         \
                                                    PASS_MEM_STAT);       \
                                                                          \
  return extend;                                                          \
}                                                                         \

and the mis-compile happens when computing the "space" predicate.  Due to the
particular circumstances, the effect is that the "reserve_exact" routine is
actually called, but nevertheless in effect "false" is returned to the caller
of the inlined routine.

In the generated assembler code, the effect can be seen most easily by
comparing the code for 
reallocated = VEC_reserve_exact (tree, gc, method_vec, 1);
with the one generated for
reallocated = VEC_reserve (tree, gc, method_vec, 1);

In the latter case, we get the following snippet for computing "space":

 82ec7de:       85 db                   test   %ebx,%ebx
 82ec7e0:       0f 84 d9 00 00 00       je     82ec8bf <add_method+0x90f>
 82ec7e6:       8b 33                   mov    (%ebx),%esi
 82ec7e8:       31 c9                   xor    %ecx,%ecx
 82ec7ea:       39 73 04                cmp    %esi,0x4(%ebx)
 82ec7ed:       0f 94 c1                sete   %cl
 82ec7f0:       89 ce                   mov    %ecx,%esi
 82ec7f2:       0f 84 cc 00 00 00       je     82ec8c4 <add_method+0x914>

Note the "sete", which in effect sets the returned boolean value.

However, in the same snippet for the "reserve_exact" branch, we have instead:

 82ec0d9:       85 db                   test   %ebx,%ebx
 82ec0db:       0f 84 4c 07 00 00       je     A1: 82ec82d <add_method+0x87d> 
 82ec0e1:       8b 2b                   mov    (%ebx),%ebp
 82ec0e3:       31 c0                   xor    %eax,%eax
 82ec0e5:       39 6b 04                cmp    %ebp,0x4(%ebx)
 82ec0e8:       89 c6                   mov    %eax,%esi
 82ec0ea:       0f 84 42 07 00 00       je     A2: 82ec832 <add_method+0x882>

Note how the "sete" is missing, and "esi" is always set to zero.


This bug is introduced at the if-conversion stage ("ce3" pass).  Before that,
we have the following RTL:

(insn 1908 1810 1909 177 xxx.i:13972 (parallel [
            (set (reg/v:SI 0 ax [orig:195 extend ] [195])
                (const_int 0 [0x0]))
            (clobber (reg:CC 17 flags))
        ]) -1 (nil))

(insn 1909 1908 1910 177 xxx.i:13972 (set (reg:CCZ 17 flags)
        (compare:CCZ (mem/s:SI (plus:SI (reg/v/f:SI 3 bx [orig:94 method_vec ]
[94])
                    (const_int 4 [0x4])) [15 method_vec_511->base.alloc+0 S4
A32])
            (reg:SI 2 cx))) -1 (nil))

(insn 1910 1909 1114 177 xxx.i:13972 (set (strict_low_part (reg:QI 0 ax
[orig:195 extend ] [195]))
        (eq:QI (reg:CCZ 17 flags)
            (const_int 0 [0x0]))) -1 (nil))

(jump_insn 1114 1910 1115 177 xxx.i:13972 (set (pc)
        (if_then_else (ne (reg:CCZ 17 flags)
                (const_int 0 [0x0]))
            (label_ref:SI 1173)
            (pc))) 464 {*jcc_1} (expr_list:REG_DEAD (reg:CCZ 17 flags)
        (expr_list:REG_BR_PROB (const_int 8371 [0x20b3])
            (nil)))
 -> 1173)

(note 1115 1114 1116 178 [bb 178] NOTE_INSN_BASIC_BLOCK)

(insn 1116 1115 1575 178 xxx.i:13972 (set (reg/v:QI 4 si [orig:62 reallocated ]
[62])
        (reg:QI 0 ax [orig:195 extend ] [195])) 53 {*movqi_1}
(expr_list:REG_DEAD (reg:QI 0 ax [orig:195 extend ] [195])
        (nil)))

(jump_insn 1575 1116 1576 178 (set (pc)
        (label_ref 1117)) 477 {jump} (nil)
 -> 1117)

where insn 1910 is what should result in the "sete" instruction.

However, after if-conversion, we get:

(insn 1908 1810 1116 177 xxx.i:13972 (parallel [
            (set (reg/v:SI 0 ax [orig:195 extend ] [195])
                (const_int 0 [0x0]))
            (clobber (reg:CC 17 flags))
        ]) -1 (nil))

(insn 1116 1908 1909 177 xxx.i:13972 (set (reg/v:QI 4 si [orig:62 reallocated ]
[62])
        (reg:QI 0 ax [orig:195 extend ] [195])) 53 {*movqi_1}
(expr_list:REG_DEAD (reg:QI 0 ax [orig:195 extend ] [195])
        (nil)))

(insn 1909 1116 1910 177 xxx.i:13972 (set (reg:CCZ 17 flags)
        (compare:CCZ (mem/s:SI (plus:SI (reg/v/f:SI 3 bx [orig:94 method_vec ]
[94])
                    (const_int 4 [0x4])) [15 method_vec_511->base.alloc+0 S4
A32])
            (reg:SI 2 cx))) -1 (nil))

(insn 1910 1909 1114 177 xxx.i:13972 (set (strict_low_part (reg:QI 0 ax
[orig:195 extend ] [195]))
        (eq:QI (reg:CCZ 17 flags)
            (const_int 0 [0x0]))) -1 (nil))

(jump_insn 1114 1910 1924 177 xxx.i:13972 (set (pc)
        (if_then_else (eq (reg:CCZ 17 flags)
                (const_int 0 [0x0]))
            (label_ref:SI 1117)
            (pc))) 464 {*jcc_1} (expr_list:REG_DEAD (reg:CCZ 17 flags)
        (expr_list:REG_BR_PROB (const_int 1629 [0x65d])
            (nil)))
 -> 1117)

(note 1924 1114 1925 178 [bb 178] NOTE_INSN_BASIC_BLOCK)

(jump_insn 1925 1924 1926 178 (set (pc)
        (label_ref 1173)) -1 (nil)
 -> 1173)


Note how insn 1116 has now been moved to *before* insn 1910, so that it uses an
incorrect value of "ax", and insn 1910 is effectively dead code (which gets
deleted later).

The reason for this is apparently a bug in the data-flow analysis done by the
if-conversion pass when trying to determine whether an instruction can be moved
to a different location.

This bug, it seems, has been detected independently in a different situation
and fixed (in time for 4.6) by Bernd Schmidt by this series of patches:

http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00745.html
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00857.html
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg01005.html

See the discussion around those patches for details on the data-flow bug.

I've backported these three patches to the 4.5 branch, and this fixes the
problem for me (profiled-bootstrap works again).

[Bug middle-end/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV

[uweigand at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43085

--- Comment #23 from Ulrich Weigand <uweigand at gcc dot gnu.org> 2011-04-27 16:28:32 UTC ---
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02131.html

[Bug middle-end/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV

[uweigand at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43085

Ulrich Weigand <uweigand at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #25 from Ulrich Weigand <uweigand at gcc dot gnu.org> 2011-05-02 14:07:47 UTC ---
Fixed.

[Bug middle-end/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV

[uweigand at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43085

--- Comment #24 from Ulrich Weigand <uweigand at gcc dot gnu.org> 2011-05-02 14:06:52 UTC ---
Author: uweigand
Date: Mon May  2 14:06:48 2011
New Revision: 173252

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173252
Log:
2011-05-02  Ulrich Weigand  <ulrich.weigand@linaro.org>

    PR middle-end/43085
    Backport from mainline:

    2010-04-29  Bernd Schmidt  <bernds@codesourcery.com>

    From Dominique d'Humieres <dominiq@lps.ens.fr>
    PR bootstrap/43858
    * ifcvt.c (dead_or_predicable): Use df_simulate_find_defs to compute
    test_set.

    2010-04-26  Bernd Schmidt  <bernds@codesourcery.com>

    * df-problems.c (df_simulate_initialize_forwards): Set, don't clear,
    bits for artificial defs at the top of the block.
    * fwprop.c (single_def_use_enter_block): Don't call it.

    2010-04-22  Bernd Schmidt  <bernds@codesourcery.com>

    * ifcvt.c (dead_or_predicable): Use df_simulate_find_defs and
    df_simulate_find_noclobber_defs as appropriate.  Keep track of an
    extra set merge_set_noclobber, and use it to relax the final test
    slightly.
    * df.h (df_simulate_find_noclobber_defs): Declare.
    * df-problems.c (df_simulate_find_defs): Don't ignore partial or
    conditional defs.
    (df_simulate_find_noclobber_defs): New function.

Modified:
    branches/gcc-4_5-branch/gcc/ChangeLog
    branches/gcc-4_5-branch/gcc/df-problems.c
    branches/gcc-4_5-branch/gcc/df.h
    branches/gcc-4_5-branch/gcc/fwprop.c
    branches/gcc-4_5-branch/gcc/ifcvt.c