Summary: | [4.3/ICE] sys-devel/gcc-4.3.1 emerge fails. Segmentation fault. libiberty/hashtab.c:554: internal compiler error | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Paul Gibbons <paul> |
Component: | [OLD] GCC Porting | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | aagaande, gengor, grobian, kfm, leon, loki_val, pchrist, rabbe, toovey, vslavik, zorry |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Paul Gibbons
2008-06-22 18:53:00 UTC
Can you reproduce this, ie if you try again, does it fail at the same place? (In reply to comment #1) > Can you reproduce this, ie if you try again, does it fail at the same place? > Yes - reproduced with exactly same error message twice. Paul: I'd suggest trying first to eliminate the Wno-error CFLAG. It might be that which is throwing it off. toolchain: Do a google-search for hashtab.c:554 . This looks like the real McCoy, re-arisen from the dead, or... Something. (In reply to comment #4) > Paul: > I'd suggest trying first to eliminate the Wno-error CFLAG. It might be that > which is throwing it off. > > toolchain: > Do a google-search for hashtab.c:554 . This looks like the real McCoy, > re-arisen from the dead, or... Something. > Thanks for the suggestion Peter but eliminating Wno-error had no effect. Seg fault at same place: /var/tmp/portage/sys-devel/gcc-4.3.1/work/build/./prev-gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-4.3.1/work/build/./prev-gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -c -DHAVE_CONFIG_H -march=k8 -pipe -fprofile-use -I. -I/var/tmp/portage/sys-devel/gcc-4.3.1/work/gcc-4.3.1/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic -fpic /var/tmp/portage/sys-devel/gcc-4.3.1/work/gcc-4.3.1/libiberty/hashtab.c -o pic/hashtab.o; \ else true; fi /var/tmp/portage/sys-devel/gcc-4.3.1/work/gcc-4.3.1/libiberty/hashtab.c: In function 'htab_expand': /var/tmp/portage/sys-devel/gcc-4.3.1/work/gcc-4.3.1/libiberty/hashtab.c:554: internal compiler error: Segmentation fault I had problems with gcc.4.2.1 for which I had to remove -O2 flag. Does this give a clue - could it be a hardware issue? I can confirm this, with gcc 4.1.2 on a 64bit install. LDFLAGS=" " CFLAGS=" " CXXFLAGS=" " emerge -1 gcc produces the exact same output. I just tried this with gcc 4.3.1 and gcc 4.3.1-r1, they both segfault. going gcc 4.1.2 -> 4.2.4 -> 4.3.1 worked. *** Bug 237225 has been marked as a duplicate of this bug. *** (In reply to comment #8) > going gcc 4.1.2 -> 4.2.4 -> 4.3.1 worked. Not for me... The segfault is caused by -fprofile-use passed to gcc when compiling this file -- removing it fixes the crash (at the cost of presumably worse performance of the created compiler). *** Bug 244479 has been marked as a duplicate of this bug. *** Upstream bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33992 As a quick fix, using "bootstrap-lean" target instead of "profiledbootstrap" in toolchain.eclass helps. this is part of gcc-4.3.2 mainline release (In reply to comment #13) > this is part of gcc-4.3.2 mainline release You are once again a bit too trigger happy when it comes to closing bugs. The bug still exists with 4.3.2 ebuild in portage, so no, this definitely wasn't fixed in 4.3.2. Somebody with sufficient permissions to reopen this bug, please do so. Concur with comment #14. The issue has not yet been fixed. I ran into the same problem trying to build gcc-4.3.2-r2 with gcc-3.4.6-r2 on an amd64 host. I tried many things: * Nullifying CFLAGS to keep BOOT_CFLAGS clean and various other build settings * Installing a tinderbox package of gcc-4.1.2 and setting that as the active compiler * Trying various other make targets than bootstrap-lean (which has recently been made the default in toolchain.eclass) In the end, the _only_ thing that worked was to use "make bootstrap4" which employs a 4-stage bootstrap process rather than the usual 3-stage process entailed by "bootstrap" and "bootstrap-lean". After changing toolchain.eclass accordingly, it compiled beautifully for the first time. Using bootstrap4 seems to reduce the likelihood of spurious build failures a lot. In fact, it's so reliable that I'm even able to carry out a full bootstrap process - as in running gentoo's bootstrap.sh script - with gcc-3.4.6-hardened specs active, leading up to a working gcc-4.3.2-r2 compiler with the recently committed (and experimental) hardened specs! In other words, that constitutes as challenging a scenario for the gcc bootstrap phase as one might expect to encounter and it passes with flying colours. So, given that: * This bug is still in evidence as seen here and in mailing list posts * bootstrap4 isn't much slower than bootstrap/bootstrap-lean * We've gained massive time savings from dropping profiledbootstrap anyway * Hardened might reasonably wish to provide a safe upgrade path for their userbase in the near future * It's by no means a hardened-specific problem anyway ... is there not a case for adopting it? vaclav, the bug you referenced was fixed pre-4.3.0, so this must be something else. also we stopped using profiledbootstrap altogether recently. kerin, i'm not sure why bootstrap4 would work around this. if it's ICEing in an earlier stage why would adding another fix it? do you have a full build log of the failure handy (preferably without any changes to eclasses/CFLAGS/etc ;))? profiledbootstrap isnt used anymore by default > profiledbootstrap isnt used anymore by default Indeed, although the problem I faced was not triggered by profiledbootstrap in the first instance. > kerin, i'm not sure why bootstrap4 would work around this Firstly, sorry for taking so long to get back to you (and in particular for creating noise after the bug has been closed). Neither am I able to offer a reasonable explanation as to why using the bootstrap4 target worked around the issue at the time, but I can assure you that it did in a manner that was entirely reproducible. Anyway, I'm posting back here to say that - just for the record - the real issue turned out to be with the kernel: http://bugs.gentoo.org/show_bug.cgi?id=254843#c13 That's since been resolved so all is well :) |