Summary: | Emerge of gcc-3.4.2-r2 gives internal compiler error: Illegal instruction | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Lars Petersen <lars> |
Component: | [OLD] Core system | Assignee: | Docs Team <docs-team> |
Status: | RESOLVED WONTFIX | ||
Severity: | critical | CC: | Sebastian |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | ccsynhkD.out |
Description
Lars Petersen
2004-09-27 20:07:08 UTC
Created attachment 40578 [details]
ccsynhkD.out
The error said to send this file along with the bug report!
I can confirm this bug. I get the same "crash" on a Nehemica C3 processor .../gcc-3.4.2-r2/work/gcc-3.4.2/gcc/libgcc2.c: In function `__floatdisf': .../gcc-3.4.2-r2/work/gcc-3.4.2/gcc/libgcc2.c:1342: internal compiler error: illegal instruction uname: Linux 2.6.4-rc1 i686 VIA Nehemiah CentaurHauls GNU/Linux If needed I can post the crash .out file. FYI: Old C3 CPUs did not have the CMOV instruction, so a i686 compilation would crash because of that. Newer C3 CPUS, such as the Nehemiah do have the CMOV instruction, so it shouldn't be because of this. I'll check some gcc bug sites and report back if I find anything interesting. I saw that we both have the newer Nehemiah core but use march/mcpu=c3. This might be the culprit. A post (admittedly from Feb 2003) from Dave Jones states that: "The Nehemiah (model 9) core of the VIA C3 is significantly different from the earlier C3s. It now has cmov (so we can generate i686 code for it now), and it dropped 3dnow, and implements SSE instead. This means that the existing -march=c3 will generate code that the C3-2 cannot run (and vice versa)" <http://gcc.gnu.org/ml/gcc-patches/2003-02/msg00653.html> So it might simply be that we need a different mcpu/march option. This VIA site suggests to use mcpu/march i696 for a Via Nehemiah: <http://www.viaarena.com/Default.aspx?PageID=5&ArticleID=61> I am compiling gcc with mcpu=i686 right now and will report back if that fails as well. Otherwise we would simply need to include in some documentation (handbook, make.conf.example ?) that Nehemiah and newer C3 CPUs should use i686 as a target. (A C3-2 option was discussed but hasn't been implemented so far). so... did that do it? /var/tmp/portage/gcc-3.4.2-r2/work/gcc-3.4.2/libiberty/cplus-dem.c: In function `demangle_qualified': /var/tmp/portage/gcc-3.4.2-r2/work/gcc-3.4.2/libiberty/cplus-dem.c:3310: warning : implicit declaration of function `atoi' make[1]: *** [cplus-dem.o] Error 1 make[1]: Leaving directory `/var/tmp/portage/gcc-3.4.2-r2/work/build/i686-pc-lin ux-gnu/libiberty' make: *** [all-target-libiberty] Error 2 !!! ERROR: sys-devel/gcc-3.4.2-r2 failed. !!! Function gcc_do_make, Line 916, Exitcode 2 !!! (no error message) !!! If you need support, post the topmost build error, NOT this status message. # emerge info Portage 2.0.51_rc7 (default-x86-2004.2, gcc-3.3.3, glibc-2.3.3.20040420-r0, 2.6.9-rc3 i686) ================================================================= System uname: 2.6.9-rc3 i686 Pentium II (Deschutes) Gentoo Base System version 1.5.3 distcc 2.17 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 Headers: sys-kernel/linux-headers-2.4.22 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=pentium2 -O3 -pipe -fomit-frame-pointer -funroll-loops -ftracer -ffast-math -fprefetch-loop-arrays" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium2 -O3 -pipe -fomit-frame-pointer -funroll-loops -ftracer -ffast-math -fprefetch-loop-arrays" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache distcc distlocks fixpackages sandbox" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo/" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" USE="apm avi berkdb bitmap-fonts crypt cups encode foomaticdb gdbm gif gpm gtk gtk2 imap imlib jpeg libg++ libwww mad mikmod motif mpeg ncurses nls oggvorbis opengl oss pam pdflib perl png python quicktime readline sdl slang spell ssl svga tcpd truetype x86 xml2 xmms xprint xv zlib" RE: comment #4 From Travis Tilley: so... did that do it? Yes, setting -march i686 solved all my problems, it compiles like a charm. So no bug involved here, the solution for newer Via C3 CPUs (>Nehemiah) is simply to set -march=i686. It should still be recorded somewhere in the appropriate docs. Jonathans issue from comment #5 seems unrelated to the issue reported here... Ok then. toolchain is all done with this bug. Passing along to the docs team so it can be noted somewhere. Swift/other. See comment #6 Oh come on, our docs don't inform users about -march=c3, if they choose this it means they got that from somewhere else. Locate the source and adjust that. Even our make.conf.example file doesn't list "c3". Not that c3 is illegal or anything, I just feel that there are other locations where this should be put. |