http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686
--- Comment #35 from Rainer Orth <ro at gcc dot gnu.org> 2013-04-03 12:19:13 UTC --- Created attachment 29792 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29792 new testcase After some digging, I found a bit of what's going on: for a long time (before 4.7 branched) I'd been building on IRIX 6.5 with --enable-checking=release since that cuts down bootstrap time by ca. 30% to ca. 36 hours. At some time after the release, I dropped that, assuming that it were the default on a release branch, which is not true unfortunately. I've now been able to massively the libstdc++ vec.cc failure and reproduce it in a i386-pc-solaris2.11 x mips-sgi-irix6.5 cross compiler configured with --disable-nls --target mips-sgi-irix6.5 \ --with-gmp-include=/vol/gcc/include --with-gmp-lib=/vol/gcc/lib \ --disable-libgomp --disable-libquadmath --disable-libssp --disable-lto \ --enable-obsolete --enable-languages=c,c++ --enable-checking The --enable-checking is the key here. With such a cc1plus, I get the following ICE: % ./cc1plus -fpreprocessed vec.ii -quiet -mabi=n32 -g -O2 -o vec.s vec.ii: In function 'void __cxxabiv1::__cxa_vec_delete2(void*, std::size_t, std::size_t, __cxxabiv1::__cxa_cdtor_type, void (*)(void*))': vec.ii:55:3: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2231 Rainer
