Bug #759409 “Profiled bootstrap fails in FSF GCC 4.5” : Bugs : Linaro GCC

Revision history for this message

In GCC Bugzilla #43085, Aanisimov (aanisimov) wrote on 2010-02-15:

#3

Download full text (4.8 KiB)

I configured GCC rev. 156770 with the following options:

../gcc/configure --prefix=/home/artem/testing/gcc45 --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=i686 --target=i686-slackware-linux --build=i686-slackware-linux --host=i686-slackware-linux

With this configuration 'make' completes successfully, but 'make profiledbootstrap' fails.

The last command which gets executed is

/home/artem/testing/gcc-build/./gcc/xgcc -shared-libgcc -B/home/artem/testing/gcc-build/./gcc -nostdinc++ -L/home/artem/testing/gcc-build/i686-slackware-linux/libstdc++-v3/src -L/home/artem/testing/gcc-build/i686-slackware-linux/libstdc++-v3/src/.libs -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 -I/home/artem/testing/gcc-build/i686-slackware-linux/libstdc++-v3/include/i686-slackware-linux -I/home/artem/testing/gcc-build/i686-slackware-linux/libstdc++-v3/include -I/home/artem/testing/gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -c ../../../../gcc/libstdc++-v3/src/pool_allocator.cc -fPIC -DPIC -o .libs/pool_allocator.o

While compiling pool_allocator.o, cc1plus catches SIGSEGV:

In file included from ../../../../gcc/libstdc++-v3/src/pool_allocator.cc:31:0:
/home/artem/testing/gcc-build/i686-slackware-linux/libstdc++-v3/include/ext/pool_allocator.h: In constructor '__gnu_cxx::__pool_alloc<_Tp>::__pool_alloc() [with _Tp = char]':
../../../../gcc/libstdc++-v3/src/pool_allocator.cc:171:18: instantiated from here
/home/artem/testing/gcc-build/i686-slackware-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.

Here is the backtrace:

#0 0xb6ff08c7 in raise () from /lib/libc.so.6
#1 0xb6ff2132 in abort () from /lib/libc.so.6
#2 0x08269204 in real_abort () at ../../gcc/gcc/diagnostic.c:738
#3 diagnostic_action_after_output () at ../../gcc/gcc/diagnostic.c:201
#4 0x08269b09 in diagnostic_report_diagnostic (context=0x89ee8e0, diagnostic=0xbfcbfa94) at ../../gcc/gcc/diagnostic.c:423
#5 0x0826986a in internal_error (gmsgid=0x885c7ad "%s") at ../../gcc/gcc/diagnostic.c:674
#6 0x083fefe0 in crash_signal (signo=11) at ../../gcc/gcc/toplev.c:629
#7 <signal handler called>
#8 0x080c8ea4 in build_new_method_call (instance=0xb6aaf508, fns=0x0, args=0xbfcc019c, conversion_path=0xb6c886c8, flags=3,
complain=3, fn_p=0x0) at ../../gcc/gcc/cp/call.c:6209
#9 0x080ca084 in build_special_member_call (instance=0xb6aaf508, name=0xb6cf90d0, args=0xbfcc019c,
binfo=<value optimized out>, flags=3, complain=3) at ../../gcc/gcc/cp/call.c:6115
#10 0x0817aa69 in expand_default_in...

Created attachment 20640
this file triggers ICE in cc1plus

i have exactly the same, affects 4.5.0 release and current gcc-4_5-branch

../${SRCDIR}/configure --prefix=/usr/local/gcc-4.5 --host=i586-sylvia-linux --build=i586-sylvia-linux --with-pkgversion=/argenta/ --disable-nls --with-cpu=pentium4 --with-arch=pentium4 --enable-languages=c,c++ --enable-threads --enable-tls --with-host-libstdcxx='/usr/local/gcc-4.5/lib/libstdc++.a -lm' --with-gmp=/var/tmp --with-mpfr=/var/tmp --with-ppl=/var/tmp --with-cloog=/var/tmp --with-mpc=/var/tmp --with-libelf=/var/tmp --enable-lto --with-fpmath=sse

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.1pre_100512_r159302/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -O2 -g -march=pentium4 -D_GNU_SOURCE -c ../../../../gcc-4.5.1pre_100512_r159302/libstdc++-v3/src/pool_allocator.cc  -fPIC -DPIC -o .libs/pool_allocator.o
In file included from ../../../../gcc-4.5.1pre_100512_r159302/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.1pre_100512_r159302/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
make[4]: Leaving directory `/var/tmp/gccbuild/i586-sylvia-linux/libstdc++-v3/src'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/var/tmp/gccbuild/i586-sylvia-linux/libstdc++-v3'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/var/tmp/gccbuild/i586-sylvia-linux/libstdc++-v3'
make[1]: *** [all-target-libstdc++-v3] Error 2
make[1]: Leaving directory `/var/tmp/gccbuild'
make: *** [profiledbootstrap] Error 2

line 171: pool_allocator.cc 
  template class __pool_alloc<char>;

line 140: pool_allocator.h
      __pool_alloc() throw() { }

backtrace:
(gdb) set args -fpreprocessed pool_allocator.ii -quiet -dumpbase pool_allocator.ii -march=pentium4 -auxbase pool_allocator -g -O2 -Wall -Wextra -Wwrite-strings -Wcast-qual -version -fno-implicit-templates -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -o assembl.s
(gdb) show args
Argument list to give program being debugged when it is started is "-fpreprocessed pool_allocator.ii -quiet -dumpbase pool_allocator.ii -march=pentium4 -auxbase pool_allocator -g -O2 -Wall -Wextra -Wwrite-strings -Wcast-qual -version -fno-implicit-templates -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -o assembl.s".
(gdb) run
Starting program: /tmp/cc1plus -fpreprocessed pool_allocator.ii -quiet -dumpbase pool_allocator.ii -march=pentium4 -auxbase pool_allocator -g -O2 -Wall -Wextra -Wwrite-strings -Wcast-qual -version -fno-implicit-templates -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -o assembl.s
GNU C++ /argenta/ version 4.5.1 (i586-sylvia-linux)
        compiled by GNU C version 4.5.1, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ /argenta/ version 4.5.1 (i586-sylvia-linux)
        compiled by GNU C version 4.5.1, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 4b0d4a6436cff7650a243477151f465b

Program received signal SIGSEGV, Segmentation fault.
0x083b5d5a in build_new_method_call.clone.3 ()
(gdb) bt
#0  0x083b5d5a in build_new_method_call.clone.3 ()
#1  0x00000000 in ?? ()
(gdb) 
not very long because on my gentoo system everything has been compiled with -fomit-frame-pointer, but this GCC build which is "-O2 -g -march=pentium4", with any other flags there is same ICE too

Revision history for this message

In GCC Bugzilla #43085, Fierevere-mail (fierevere-mail) wrote on 2010-05-12:

#5

Please change:

component to bootstrap
Host/Target and Build to i686-pc-linux-gnu
set higher priority and severity, this problem makes profiledbootstrap make target unable to build and FDO-built GCC unusable, its definitely not "normal" severity and not really a P3 prio !

Tested on current rev 159302 from svn branches/gcc-4_5-branch

Revision history for this message

In GCC Bugzilla #43085, Sylvia (fierevere) wrote on 2010-09-01:

#6

In file included from ../../../../gcc-4.5.2pre-20100901-rev163742/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-20100901-rev163742/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,

still ICE'ing, revision 163742 , GCC 4.5.2prerelease from branches/

Revision history for this message

In GCC Bugzilla #43085, Matthias Klose (doko) wrote on 2010-09-06:

#7

I can confirm this with 20100902 from the 4.5 branch. the profiled bootstrap did work with the 4.5.1 release.

Revision history for this message

In GCC Bugzilla #43085, Pinskia (pinskia) wrote on 2010-09-15:

#8

*** Bug 45684 has been marked as a duplicate of this bug. ***

Revision history for this message

In GCC Bugzilla #43085, Rguenth (rguenth) wrote on 2010-09-16:

#9

With seeing .clone in fn names I suppose this is ipa-cp or ipa-sra.

Revision history for this message

In GCC Bugzilla #43085, Jamborm (jamborm) wrote on 2010-10-11:

#10

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.

Revision history for this message

In GCC Bugzilla #43085, Aanisimov (aanisimov) wrote on 2010-10-12:

#11

(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.

(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.

Revision history for this message

In GCC Bugzilla #43085, Aanisimov (aanisimov) wrote on 2010-10-12:

#12

(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.

Revision history for this message

In GCC Bugzilla #43085, Sylvia (fierevere) wrote on 2010-10-13:

#13

(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

(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

Revision history for this message

In GCC Bugzilla #43085, Jamborm (jamborm) wrote on 2010-10-13:

#14

Right, I tried again and with "release" checking I get a segfault too. I'll examine this closer.

Revision history for this message

In GCC Bugzilla #43085, Sylvia (fierevere) wrote on 2010-10-13:

#15

(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?

Revision history for this message

In GCC Bugzilla #43085, Aanisimov (aanisimov) wrote on 2010-10-13:

#16

> 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?

Revision history for this message

In GCC Bugzilla #43085, Jamborm (jamborm) wrote on 2010-12-16:

#17

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.

Revision history for this message

In GCC Bugzilla #43085, Jamborm (jamborm) wrote on 2010-12-21:

#18

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.

Revision history for this message

In GCC Bugzilla #43085, Onur Küçük (onur-pardus) wrote on 2010-12-21:

#19

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.

Revision history for this message

In GCC Bugzilla #43085, Onur Küçük (onur-pardus) wrote on 2010-12-21:

#20

I see this with i686 btw, x86-64 seems ok

Revision history for this message

In GCC Bugzilla #43085, Onur Küçük (onur-pardus) wrote on 2011-02-28:

#21

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

Revision history for this message

In GCC Bugzilla #43085, Onur Küçük (onur-pardus) wrote on 2011-02-28:

#22

Created attachment 23488
revert 167492 patch

Michael Hope (michaelh1) on 2011-04-13

Changed in gcc-linaro:
status:	New → Triaged
importance:	Undecided → Medium

Revision history for this message

Ira Rosen (irar) wrote on 2011-04-13: AUTO: Ira Rosen is out of the office. (returning 17/04/2011)

#1

I am out of the office until 17/04/2011.

Note: This is an automated response to your message "[Bug 759409] [NEW]
Profiled bootstrap fails" sent on 13/4/2011 7:18:51.

This is the only notification you will receive while this person is away.

Revision history for this message

Michael Hope (michaelh1) wrote on 2011-04-13: Re: Profiled bootstrap fails

#2

Recent upstream 4.5 branch also fails but in a different way:
http://builds.linaro.org/toolchain/gcc-4.5+svn172238^profiled

The 4.6.0 release builds fine:
http://ex.seabright.co.nz/build/gcc-4.6.0%5Eprofiled/logs/i686-lucid-cbuild109-scorpius-profiled/

Revision history for this message

In GCC Bugzilla #43085, Michael Hope (michaelh1) wrote on 2011-04-13:

#23

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.

Revision history for this message

In GCC Bugzilla #43085, Sylvia (fierevere) wrote on 2011-04-13:

#24

Sorry, this mail address it not being used anymore, this message has been sent automatically.
Извините, этот адрес более не используется, это сообщение было отправлено автоматически.

Bug Watch Updater (bug-watch-updater) on 2011-04-13

Changed in gcc:
importance:	Unknown → Medium
status:	Unknown → Confirmed

Revision history for this message

Michael Hope (michaelh1) wrote on 2011-04-13: Re: Profiled bootstrap fails

#25

I see similar on ARM:
http://builds.linaro.org/toolchain/gcc-linaro-4.5+bzr99492%5Eprofiled/logs/armv7l-maverick-cbuild109-ursa1-cortexa9r1/gcc-build.txt

../../../gcc-linaro-4.5/gcc/gengtype.c: In function 'write_types_process_field':
../../../gcc-linaro-4.5/gcc/gengtype.c:2458:3: internal compiler error: in set_jump_prob, at stmt.c:2319

../../../gcc-linaro-4.5/gcc/read-rtl.c: In function 'apply_iterator_traverse':
../../../gcc-linaro-4.5/gcc/read-rtl.c:548:3: internal compiler error: Floating point exception

Revision history for this message

Michael Hope (michaelh1) wrote on 2011-04-15:

#26

gcc-linaro-4.6+bzr106732 bootstraps OK on i686.

Revision history for this message

Ulrich Weigand (uweigand) wrote on 2011-04-18:

#27

I can confirm the failure with Linaro GCC 4.5. The problem is an integer division by zero in set_jump_prob, which is a new function added as part of a feature ported from the CodeSourcery tree:

2010-01-25 Tom de Vries <email address hidden>

        gcc/
        * stmt.c (emit_case_bit_tests): Change prototype.
        * stmt.c (struct case_bit_test): Add prob field.
        * stmt.c (get_label_prob): New function.
        * stmt.c (set_jump_prob): New function.
        * stmt.c (emit_case_bit_tests): Use get_label_prob.
        * stmt.c (emit_case_bit_tests): Set prob field.
        * stmt.c (emit_case_bit_tests): Use set_jump_prob.
        * stmt.c (expand_case): Add new args to emit_case_bit_tests invocation.
        * testsuite/gcc.dg/switch-prob.c: Add test.

This particular CodeSourcery backport is not (yet?) in Linaro GCC 4.6, therefore the problem cannot occur there.

Revision history for this message

Ulrich Weigand (uweigand) wrote on 2011-04-18:

#28

Note that the failure with FSF 4.5 branch (which I wasn't able to reproduce so far) must be a separate problem from the set_jump_prob issue specific to Linaro GCC. Probably should be a separate LP bug ...

Revision history for this message

Ulrich Weigand (uweigand) wrote on 2011-04-18:

#29

Hmm, now I'm able to reproduce the FSF 4.5 failure as well. Turns out it only happens if you do *not* configure with --enable-checking (as I usually do) ...

Revision history for this message

In GCC Bugzilla #43085, Uweigand-gcc (uweigand-gcc) wrote on 2011-04-27:

#33

Download full text (9.3 KiB)

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) **ve...

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).

Revision history for this message

In GCC Bugzilla #43085, Uweigand-gcc (uweigand-gcc) wrote on 2011-04-27:

#34

Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02131.html

Revision history for this message

Ulrich Weigand (uweigand) wrote on 2011-04-27:

#30

Patch for the FSF 4.5 failure posted here:
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02131.html

Revision history for this message

Ulrich Weigand (uweigand) wrote on 2011-04-27:

#31

Split bug into two LP's to track the two problems separately, and assigned myself to this one.

summary:	- Profiled bootstrap fails + Profiled bootstrap fails in FSF GCC 4.5
description:	updated
Changed in gcc-linaro:
status:	Triaged → In Progress
assignee:	nobody → Ulrich Weigand (uweigand)

Revision history for this message

In GCC Bugzilla #43085, Uweigand-gcc (uweigand-gcc) wrote on 2011-05-02:

#35

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 <email address hidden>

PR middle-end/43085
Backport from mainline:

2010-04-29 Bernd Schmidt <email address hidden>

From Dominique d'Humieres <email address hidden>
PR bootstrap/43858
* ifcvt.c (dead_or_predicable): Use df_simulate_find_defs to compute
test_set.

2010-04-26 Bernd Schmidt <email address hidden>

* 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 <email address hidden>

* 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

Revision history for this message

In GCC Bugzilla #43085, Uweigand-gcc (uweigand-gcc) wrote on 2011-05-02:

#36

Fixed.

Revision history for this message

Ulrich Weigand (uweigand) wrote on 2011-05-02:

#32

Fix checked into FSF GCC 4.5 rev. 173252

Bug Watch Updater (bug-watch-updater) on 2011-05-03

Changed in gcc:
status:	Confirmed → Fix Released

Ulrich Weigand (uweigand) on 2011-05-17

Changed in gcc-linaro:
status:	In Progress → Fix Committed
milestone:	none → 4.5-2011.05-0

Michael Hope (michaelh1) on 2011-05-19

Changed in gcc-linaro:
status:	Fix Committed → Fix Released

Linaro GCC

Profiled bootstrap fails in FSF GCC 4.5

Bug Description

Other bug subscribers

Remote bug watches

Affects		Status	Importance	Assigned to	Milestone
	Linaro GCC	Fix Released	Medium	Ulrich Weigand	Linaro GCC 4.5-2011.05-0
	gcc	Fix Released	Medium	gcc-bugzilla #43085