bootstrap failure: libstdc++-v3/include/stdc++.h:83

Andrew Pinski pinskia@physics.uc.edu
Wed Jul 9 12:20:00 GMT 2003


On Wednesday, Jul 9, 2003, at 07:41 US/Eastern, Andreas Schwab wrote:

> Gerald Pfeifer <gerald@pfeifer.com> writes:
>
> |> I don't know what might be causing this, but might this be due to  
> one
> |> of the large changes by you (Mark, Jan) in the last 18 hours?
> |>
> |> Given that nobody else reported this, it might be i386 specific (as
> |> opposed to i686 etc.).
> |>
> |> /files/pfeifer/OBJ-0709-1215/gcc/xgcc -shared-libgcc  
> -B/files/pfeifer/OBJ-0709-1215/gcc/ -nostdinc++   
> -L/files/pfeifer/OBJ-0709-1215/i386-unknown-freebsd4.8/libstdc++-v3/ 
> src  
> -L/files/pfeifer/OBJ-0709-1215/i386-unknown-freebsd4.8/libstdc++-v3/ 
> src/.libs -B/sw/gcc-current/i386-unknown-freebsd4.8/bin/  
> -B/sw/gcc-current/i386-unknown-freebsd4.8/lib/ -isystem  
> /sw/gcc-current/i386-unknown-freebsd4.8/include -isystem  
> /sw/gcc-current/i386-unknown-freebsd4.8/sys-include -Winvalid-pch  
> -Wno-deprecated -x c++-header -g -O2 -nostdinc++  
> -I/files/pfeifer/OBJ-0709-1215/i386-unknown-freebsd4.8/libstdc++-v3/ 
> include/i386-unknown-freebsd4.8  
> -I/files/pfeifer/OBJ-0709-1215/i386-unknown-freebsd4.8/libstdc++-v3/ 
> include -I/sw/test/gcc/cvs/libstdc++-v3/libsupc++  
> /sw/test/gcc/cvs/libstdc++-v3/include/stdc++.h -O2 -g -o  
> ./i386-unknown-freebsd4.8/bits/stdc++.h.gch/O2g;
> |> /sw/test/gcc/cvs/libstdc++-v3/include/stdc++.h:83: internal  
> compiler error: Segmentation
> |>    fault
> |> Please submit a full bug report,
> |> with preprocessed source if appropriate.
> |> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
>
> On ia64-linux, maybe the same problem:
>
> ./libtool --mode=compile /tmp/cvs/gcc-20030709/Build/gcc/xgcc  
> -B/tmp/cvs/gcc-20030709/Build/gcc/ -B/usr/local/ia64-suse-linux/bin/  
> -B/usr/local/ia64-suse-linux/lib/ -isystem  
> /usr/local/ia64-suse-linux/include -isystem  
> /usr/local/ia64-suse-linux/sys-include -fgnu-runtime -c -o linking.lo  
> -I. -I/tmp/cvs/gcc-20030709/libobjc   -O2 -g -O2 -W -Wall  
> -Wwrite-strings -Wstrict-prototypes -DHAVE_GTHR_DEFAULT -DIN_GCC  
> -DIN_TARGET_LIBS \
> 	-I/tmp/cvs/gcc-20030709/libobjc/objc   
> -I/tmp/cvs/gcc-20030709/libobjc/../gcc  
> -I/tmp/cvs/gcc-20030709/libobjc/../gcc/config -I../../gcc  
> -I/tmp/cvs/gcc-20030709/libobjc/../include  
> /tmp/cvs/gcc-20030709/libobjc/linking.m
> /tmp/cvs/gcc-20030709/Build/gcc/xgcc  
> -B/tmp/cvs/gcc-20030709/Build/gcc/ -B/usr/local/ia64-suse-linux/bin/  
> -B/usr/local/ia64-suse-linux/lib/ -isystem  
> /usr/local/ia64-suse-linux/include -isystem  
> /usr/local/ia64-suse-linux/sys-include -fgnu-runtime -c -I.  
> -I/tmp/cvs/gcc-20030709/libobjc -O2 -g -O2 -W -Wall -Wwrite-strings  
> -Wstrict-prototypes -DHAVE_GTHR_DEFAULT -DIN_GCC -DIN_TARGET_LIBS  
> -I/tmp/cvs/gcc-20030709/libobjc/objc  
> -I/tmp/cvs/gcc-20030709/libobjc/../gcc  
> -I/tmp/cvs/gcc-20030709/libobjc/../gcc/config -I../../gcc  
> -I/tmp/cvs/gcc-20030709/libobjc/../include  
> /tmp/cvs/gcc-20030709/libobjc/linking.m  -fPIC -DPIC -o > .libs/linking.o
> In file included from /tmp/cvs/gcc-20030709/libobjc/linking.m:28:
> /tmp/cvs/gcc-20030709/libobjc/objc/objc.h: In function `sel_eq':
> /tmp/cvs/gcc-20030709/libobjc/objc/objc.h:64: internal compiler error:  
> Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> make[2]: *** [linking.lo] Error 1
> make[2]: Leaving directory  
> `/tmp/cvs/gcc-20030709/Build/ia64-suse-linux/libobjc'
> make[1]: *** [all-target-libobjc] Error 2
> make[1]: Leaving directory `/tmp/cvs/gcc-20030709/Build'
> make: *** [bootstrap] Error 2
>
> Andreas.

The Objective-C problem is a fall out from Jan Hubicka's inlining patch  
which he forgot to
set LANG_HOOKS_TREE_INLINING_ESTIMATE_NUM_INSNS for Objective-C so it  
is trying to call a
NULL function pointer.  The fix is to define  
LANG_HOOKS_TREE_INLINING_ESTIMATE_NUM_INSNS
in objc/objc-lang.c and define a more reasonable default in  
langhooks-def.h instead of
the NULL that is there now.

The libstdc++ problem Gerald is seeing is most likely a PCH related  
problem because it is
trying to precompile the libstdc++ header, most time this is a memory  
corruption bug or using
accessing some uninitialized memory.

Thanks,
Andrew Pinski



More information about the Gcc mailing list