Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 44406 - GCC crashes during emerge of pretty much anything.
Summary: GCC crashes during emerge of pretty much anything.
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] GCC Porting (show other bugs)
Hardware: x86 Linux
: Highest critical (vote)
Assignee: Please assign to toolchain
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-03-11 17:53 UTC by Timothy Miller
Modified: 2004-03-23 14:59 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Timothy Miller 2004-03-11 17:53:34 UTC
When I try to emerge "dev-db/postgresql-7.3.5", the gcc crashes.  Here is the tail end of the build:

gcc -O2 -mcpu=athlon-xp -march=athlon-xp -fomit-frame-pointer -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I. -I../../../src/include   -c -o gram.o
gram.c -MMD
y.tab.c: In function `yyparse':
y.tab.c:17410: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://bugs.gentoo.org/> for instructions.
The bug is not reproduceable, so it is likely a hardware or OS problem
make[3]: *** [gram.o] Error 1
make[3]: Leaving directory `/var/tmp/portage/postgresql-7.3.5/work/postgresql-7.3.5/src/backend/parser'
make[2]: *** [parser-recursive] Error 2
make[2]: Leaving directory `/var/tmp/portage/postgresql-7.3.5/work/postgresql-7.3.5/src/backend'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/var/tmp/portage/postgresql-7.3.5/work/postgresql-7.3.5/src'
make: *** [all] Error 2

!!! ERROR: dev-db/postgresql-7.3.5 failed.
!!! Function src_compile, Line 120, Exitcode 2
!!! (no error message)


NOTE:  This has got to be a GCC problem, because I get a very similar crash when doing "emerge mozilla".  That is specifically "net-www/mozilla-1.6-r1".





Reproducible: Always
Steps to Reproduce:
1. emerge postgresql
2.
3.

Actual Results:  
The build went part way through, and then when it got to 
compiling "/var/tmp/portage/postgresql-7.3.5/work/postgresql-
7.3.5/src/backend/parser/gram.c", GCC crashed.

Expected Results:  
Not crashed.

System information:

Athlon XP 2800+
MB: ABIT KD7 (KT400 chipset)
1 GIG of RAM
3ware RAID1 disk



Following is my "emerge info":

Gentoo Base System version 1.4.3.13
Portage 2.0.50-r1 (default-x86-2004.0, gcc-3.3.2, glibc-2.3.2-r9, 2.4.22-gentoo-
r7)
=================================================================
System uname: 2.4.22-gentoo-r7 i686 AMD Athlon(tm) XP 2800+
Autoconf: sys-devel/autoconf-2.58-r1
Automake: sys-devel/automake-1.7.7
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-O2 -mcpu=athlon-xp -march=athlon-xp -fomit-frame-pointer -pipe"
CHOST="i686-pc-linux-gnu"
COMPILER="gcc3"
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/s
hare/config /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -mcpu=athlon-xp -march=athlon-xp -fomit-frame-pointer -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs ccache sandbox"
GENTOO_MIRRORS="http://www.gtlib.cc.gatech.edu/pub/gentoo 
ftp://gentoo.mirrors.pair.com/ http://mirrors.tds.net/gentoo 
http://gentoo.mirrors.pair.com/"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY=""
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="3dnow X Xaw3d acpi aim apache2 apm arts avi berkdb bonobo cdr crypt cups 
dga directfb emacs emacs-w3 encode esd evo fbcon foomaticdb gb gd gdbm gif 
gnome gpm gtk gtk2 gtkhtml imagemagick imlib innodb java jpeg kde libg++ libgda 
libwww mad mikmod mmx motif mozilla mpeg msn mysql ncurses nls oggvorbis opengl 
oss pam pdflib perl plotutils png postgres python qt quicktime readline samba 
sasl scanner sdl slang spell sse ssl svga tcltk tcpd theora tiff truetype 
unicode usb wxwindows x86 xml xml2 xmms xv zlib"
Comment 1 Timothy Miller 2004-03-11 18:33:30 UTC
Another crash.  This time during the emerge of "x11-libs/qt-3.3.0-r1":

gcc -c -pipe -I/usr/include/mysql -I/usr/include/postgresql/server -I/usr/include/postgresql/pgsql -I/usr/include/postgresql/pgsql/server -fno-exceptions -Wall
-W -O2 -D_REENTRANT -fPIC -DQT_SHARED -DQT_TABLET_SUPPORT -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -DQT_THREAD_SUPPORT -D_LARGEFILE_SOURCE -D_LARGE_FILES -D_FILE_OFFSET_BITS=64 -DQT_NO_XINERAMA -DQT_DLOPEN_OPENGL -DQT_BUILTIN_GIF_READER=1 -DQT_NO_STYLE_MAC -DQT_NO_STYLE_AQUA -DQT_NO_STYLE_INTERLACE -DQT_NO_STYLE_WINDOWSXP -DQT_NO_STYLE_COMPACT -DQT_NO_STYLE_POCKETPC -I/var/tmp/portage/qt-3.3.0-r1/work/qt-x11-free-3.3.0/mkspecs/linux-g++ -I. -I/usr/include/freetype2 -I3rdparty/opentype -I../include -I/usr/X11R6/include -I.moc/release-shared-mt/ -o .obj/release-shared-mt/ftxopentype.o 3rdparty/opentype/ftxopentype.c
In file included from 3rdparty/opentype/ftxopentype.c:3:
3rdparty/opentype/ftxopen.c: In function `Free_Script':
3rdparty/opentype/ftxopen.c:195: warning: dereferencing type-punned pointer will break strict-aliasing rules
3rdparty/opentype/ftxopen.c: In function `Free_ScriptList':
3rdparty/opentype/ftxopen.c:277: warning: dereferencing type-punned pointer will break strict-aliasing rules
3rdparty/opentype/ftxopen.c: In function `Free_FeatureList':
3rdparty/opentype/ftxopen.c:412: warning: dereferencing type-punned pointer will break strict-aliasing rules
3rdparty/opentype/ftxopen.c: In function `Free_Lookup':
3rdparty/opentype/ftxopen.c:659: warning: dereferencing type-punned pointer will break strict-aliasing rules
3rdparty/opentype/ftxopen.c: In function `Free_LookupList':
3rdparty/opentype/ftxopen.c:740: warning: dereferencing type-punned pointer will break strict-aliasing rules
3rdparty/opentype/ftxopen.c: In function `Free_Coverage2':
3rdparty/opentype/ftxopen.c:860: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://bugs.gentoo.org/> for instructions.
The bug is not reproduceable, so it is likely a hardware or OS problem
make[1]: *** [.obj/release-shared-mt/ftxopentype.o] Error 1
make[1]: Leaving directory `/var/tmp/portage/qt-3.3.0-r1/work/qt-x11-free-3.3.0/src'
make: *** [sub-src] Error 2

!!! ERROR: x11-libs/qt-3.3.0-r1 failed.
!!! Function src_compile, Line 87, Exitcode 2
!!! (no error message)
Comment 2 Timothy Miller 2004-03-11 20:54:44 UTC
I think I can make a suggestion about what might be causing the GCC crash.  My hypothesis is that when the bootstrap GCC compiled the installed GCC, one of the optimizations being used caused the installed GCC to be build with invalid code.  GCC crashes on at least 10% of everything I try to emerge, which means that anything with lots of dependencies (like gnome or kde) is guaranteed to fail because at least one of the dependencies will fail to build.

So, the first thing to do to figure out how to get around this problem is to figure out which optimization setting is broken in GCC that caused it to build itself incorrectly.  Anyone listening?  Anyone want to work with me to figure this out?  I don't know where to start.
Comment 3 Timothy Miller 2004-03-12 23:02:56 UTC
Some further information:

I tried installing a pre-built gcc package, and that didn't fix the problem.  Very strange, no?

So I tried installing a pre-build glibc (what else could it be?), and THAT DID fix the problem.  Also very strange.

There are only two suspicious compiler flags that might have caused glibc to be built incorrectly.  They are -fomit-frame-pointer, and -march=athlon-xp.  Lots of people have used each one, but I have a feeling that using them together is broken in gcc.
Comment 4 Timothy Miller 2004-03-13 12:40:27 UTC
After reinstalling binary versions of glibc and gcc, I was able to get a LOT more to compile.  But I decided to eliminate the effect of -fomit-frame-pointer from everything, so I did "emerge -eu world".

It compiles for a while, then gcc crashes again when compiling glib-2.2.3:

 gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -DG_LOG_DOMAIN=\"GLib\" -DG_DISABLE_CAST_CHECKS -DG_DISABLE_DEPRECATED -DGLIB_COMPILATION -pthread -O2 -march=athlon-xp -pipe -Wall -c gdate.c  -fPIC -DPIC -o .libs/gdate.o
gdate.c: In function `g_date_new_dmy':
gdate.c:71: error: unable to generate reloads for:
(insn:HI 18 8 19 0 0x403309cc (set (reg:SI 5 edi [66])
        (zero_extend:SI (mem/f:HI (plus:SI (reg/f:SI 6 ebp)
                    (const_int 16 [0x10])) [4 y+0 S2 A16]))) 79 {*zero_extendhisi2_movzwl} (nil)
    (nil))
gdate.c:71: internal compiler error: in find_reloads, at reload.c:3629
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://bugs.gentoo.org/> for instructions.
The bug is not reproduceable, so it is likely a hardware or OS problem
make[3]: *** [gdate.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
 gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -DG_LOG_DOMAIN=\"GLib\" -DG_DISABLE_CAST_CHECKS -DG_DISABLE_DEPRECATED -DGLIB_COMPILATION -pthread -O2 -march=athlon-xp -pipe -Wall -c gdir.c  -fPIC -DPIC -o .libs/gdir.o
make[3]: Leaving directory `/var/tmp/portage/glib-2.2.3/work/glib-2.2.3/glib'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/var/tmp/portage/glib-2.2.3/work/glib-2.2.3/glib'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/glib-2.2.3/work/glib-2.2.3'
make: *** [all-recursive-am] Error 2

!!! ERROR: dev-libs/glib-2.2.3 failed.
!!! Function src_compile, Line 32, Exitcode 2
!!! (no error message)
Comment 5 Alexander Gabert (RETIRED) gentoo-dev 2004-03-23 01:08:05 UTC
please try to remove "march=athlon-xp" temporarily and report back, thanks

Alex
Comment 6 Timothy Miller 2004-03-23 14:59:04 UTC
In the end, I was compiling with "-g" as the only 'optimization' flag and still getting crashes.

The problem turned out to be hardware.  It didn't seem that way, since memtest86 ran for 24 hours straight on the Corsair memories I'm using with no errors.  And furthermore, I wasn't overclocking, and I was running the memories exactly as Corsair specified.  When I relaxed some of the settings, the problems cleared up.

Well, it turns out that this was a case of false advertizing on the part of Corsair.  As far as I can tell, the memories sold by Corsair are not actually designed to run at the speeds and latencies that Corsair says they are.  Rather, what they do is test the memories overclocked and perform a yield process to determine which ones appear to run at various speeds.  "Appear" is the operative word.  This, most likely, is why they refuse to even acknowledge that I have asked them several times for a spec sheet on their memory chips.