When trying to build the 20060906 gcc snapshot with gcc version 4.0.1 (built on same machine) on a (quad) multiprocessor i686 GNU/Linux|SMP system (4GB RAM), (not using ANY configure flags at all, issuing a plain "make") using the Linux 2.6.17.4 kernel (with enabled and working SMP support) I have made the observation that xgcc isn't able to complete compilation but rather cancels upon trying to compile the crt* related sources under $GCCSRC/gcc/config/i386/ with the message: "sorry, unimplemented: 64-bit mode not compiled in" (build tree size at this point ~135MB). More precisely, the following is the translation unit that fails: ./xgcc -B./ -B/usr/local/i686-pc-linux-gnu/bin/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -L/root/gcc-build/gcc/../ld -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../gcc-4.2-20060906/gcc -I../../gcc-4.2-20060906/gcc/. -I../../gcc-4.2-20060906/gcc/../include -I../../gcc-4.2-20060906/gcc/../libcpp/include -I../../gcc-4.2-20060906/gcc/../libdecnumber -I../libdecnumber -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-omit-frame-pointer \ -c ../../gcc-4.2-20060906/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o In order to verify whether this problem was specific to this particular snapshot (or to the fact that I included the g++ frontend) I did then also try to compile the latest official relase of gcc-core (with, and without g++). However this showed *identical* behaviour, regardless of the version of gcc, or whether it was supposed to be built with additional frontends or not. Given that the corresponding error message seems to suggest a platform related issue (i.e. a possibly mis-detected 32 bit architecture), I then also tried to explicitly compile gcc using the configure flag "--target=i686-pc-linux-gnu". However, this didn't change anything either: identical behaviour (likewise, I also verified whether this problem was specific to building gcc outside/within the gcc source tree, but this didn't have any effect either). To ensure that this issue wasn't related to an possibly outdated version of gnu make, I also updated gnu make to its latest official version (3.81) from gnu.org: no effect. As a next step I searched the gcc mailing lists (and google) for this particular problem and error message and came up with a couple of related discussions, suggesting similar problems on other i686/SMP platforms, too. While I have personally only tried to compile gcc >= 4.2, google findings suggest that this problem was possibly introduced with gcc versions around the 4.1 line (for example, see: http://www.gatago.com/gnu/gcc/help/24669804.html). Also, given that I previously compiled gcc 4.0.1 successfully on this very same machine, this issue must obviously have crept in somewhere in between. So, the problem doesn't appear to be specific to this system or distribution, only and the common denominator seems in fact to be gcc >= 4.1 on i686/SMP platforms. The suggested "fix" (for version 4.1.1 that is) to manually edit the corresponding Makefiles in order to add the -m32 (respectively -msse) flags to the crt*-targets, works however only parially here with gcc >=4.2, as the build would then cancel later on with identical error messages for different targets. For example, check out the following (this is what I got, after manually editing the Makefile to contain the "-m32" switch for basically all CFLAGS-related stage variables (XCFLAGS, TCFLAGS, STAGE* etc): ./xgcc -B./ -B/usr/local/i686-pc-linux-gnu/bin/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -L/root/tmp/plain/gcc/../ld -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -m32 -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -msse -c \ ../../gcc-4.2-20060906/gcc/config/i386/crtfastmath.c \ -o crtfastmath.o Interestingly, this contains also two SSE-related warnings, even though the "-msse" (as well as the -m32 switch) is now in fact provided by the Makefile, so it sort of seems as though these two flags wouldn't be properly honored by xgcc (or rather the helpers it calls). So, there really seems to be a deeper issue here (BTW:also, when actually adding these flags to the Makefile, it appeared as though the position of the flags mattered, as they seemed to be ignored whenever it was specified at the start of the command line, rather than at the end (after the corresponding source files, that is)). It seemed as though the xgcc executable would by default assume a 64 bit architecture, when trying to further isolate the problem, I managed to determine the cc1 executable that's created during compilation in the build tree as a possible offender: apparently it does in fact assume a 64 bit platform (or rather the "-m64" flag) by default, that is when I try to directly execute it from within the build tree via ./cc1, I get the same error message, i.e.: echo "int main() {return 0;}" | ./cc1 -o weirdo However, running "./cc1 -m32" will happily run normally without any errors, for example: echo "int main() {return 0;}" | ./cc1 -o weirdo -m32 While the first line would result in a basically empty plain text assembly file, the second line correctly contains: .file "" .text .globl main .type main, @function main: leal 4(%esp), %ecx andl $-16, %esp pushl -4(%ecx) pushl %ebp movl %esp, %ebp pushl %ecx movl $0, %eax popl %ecx popl %ebp leal -4(%ecx), %esp ret .size main, .-main .ident "GCC: (GNU) 4.2.0 20060906 (experimental)" .section .note.GNU-stack,"",@progbits Nonetheless, the -m32 flag doesn't appear to be retained when passing the command line over from xgcc to cc1 during the make process itself (when cc1 is run via xgcc), as cc1 then yields the same error message regardless of whether the flag was specified or not (even though, as I mentioned already, it did in fact appear as if in some situations the position of the -m32 flag within the parameter list did somehow matter). I would really appreciate it if other people with access to an i686/SMP, Linux/GNU platform could attempt to verify whether they can reproduce this problem or not, so that I can hopefully start to isolate the underlying issue, in particular I would like to know whether this can be generally cured from the gcc side of things, or if this may in fac be related to version conflicts in the underlying GNU toolchain. Please feel free to ask for additional information if required, I'll be happy to provide whatever information is needed to troubleshoot this issue, if required we could also arrange shell access. Likewise, I'd be more than happy to validate any patches you may come up with. Thanks! Mike PS: I'm going to attach detailed log files once this issue has been filed.
Created attachment 12238 [details] config.cache created by running ./configure w/o any flags
I was able to compile 20060909 on i686-linux-gnu just fine. How did you configure GCC? Did you build in the src directory? How did you invoke make to build GCC? What is the output of ./config.guess in the source directory? What is the output of uname -a? Do you have any environment variable set that could effect GCC?
Created attachment 12239 [details] config.log as created by configure
Created attachment 12240 [details] config.status as created by configure
Created attachment 12241 [details] toplevel Makefile created by configure
Created attachment 12242 [details] Makefile from gcc sub folder as created by configure
Created attachment 12243 [details] complete log from running make using "-d" debug switch
Created attachment 12244 [details] last hundred lines of the complete Makefile log w/ debug output
> I was able to compile 20060909 on i686-linux-gnu just fine. so was I, but not on a SMP (multi-processor) machine > How did you configure GCC? as I mentioned in the original report, I didn't use any configure whatsoever originally > Did you build in the src directory? as mentioned already, I did try both: inside the src directory as well as outside in separate folders > How did you invoke make to build GCC? as mentioned, I invoked it "plain", that is without any parameters. When that didn't work, I tried various approaches, among others a parallel build, as well as finally the one that contained the "-d" switch to provide the debug output that I attached. > What is the output of ./config.guess in the source directory? "i686-pc-linux-gnu" > What is the output of uname -a? "Linux syssiphus 2.6.17.4 #1 SMP PREEMPT Mon Sep 11 14:42:28 CEST 2006 i686 unknown" > Do you have any environment variable set that could effect GCC? not that I am aware of, certainly not the usual stuff (CFLAGS, CXXFLAGS, LDFLAGS etc)
> > How did you configure GCC? > as I mentioned in the original report, I didn't use any configure whatsoever originally Just for clarification: I missed to write "configure flags", of course I DID use configure!
Created attachment 12245 [details] environment variables as requested these are the environment variables that are set in bash for the root user currently
> > I was able to compile 20060909 on i686-linux-gnu just fine. > so was I, but not on a SMP (multi-processor) machine Just to summarize my original and somewhat lengthy reply: I have come to the assumption that the SMP availability somewhow makes the build assume a 64bit target, which in turn makes some intermediately created bootstrap executables (such as cc1) expect a 64bit target by default, which results in the make failing due to the ommission of the then required "-m32" switch. Nonetheless, specifying this switch manually (directly in the Makefile), does only solve part of the problem, as other targets would still fail later on.
(In reply to comment #12) No it does not. Are you sure you don't have some bad hardware?
Sorry, I just realized that I somehow managed to forget to post the actual error and warning messages: /root/tmp/plain/./gcc/xgcc -B/root/tmp/plain/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -msse -c \ ../../gcc-4.2-20060906/gcc/config/i386/crtfastmath.c \ -o crtfastmath.o ../../gcc-4.2-20060906/gcc/config/i386/crtfastmath.c:1: sorry, unimplemented: 64-bit mode not compiled in :0: sorry, unimplemented: 64-bit mode not compiled in /bin/sh ../../gcc-4.2-20060906/gcc/../move-if-change tmp-macro_list macro_list ../../gcc-4.2-20060906/gcc/config/i386/crtfastmath.c: In function 'set_fast_math': ../../gcc-4.2-20060906/gcc/config/i386/crtfastmath.c:77: warning: implicit declaration of function '__builtin_ia32_stmxcsr' echo timestamp > s-macro_list ../../gcc-4.2-20060906/gcc/config/i386/crtfastmath.c:109: warning: implicit declaration of function '__builtin_ia32_ldmxcsr' make[3]: *** [crtfastmath.o] Error 1 the error about the missing 64 bit support is exactly what I get for all the crt related files.
> No it does not. Well, as I said: it's just an assumption-for the lack of a better explanation right now. >Are you sure you don't have some bad hardware? well, define "bad hardware"-the system works without any problems whatsoever, no crashes, no performance issues, no nothing. In fact, it does compile other software without any problems, too-it even compiled gcc 4.01. So, I have really no reason to believe that this is due to some sort of hardware issue. Neither do I believe this to be some sort of gcc-internal bug. Rather, I have come to believe that somewhere along the build process (for whatever reason), gcc 4.2 is made believe that it should assume 64bit as default target platform. Otherwise, I'm really not sure why it would create an cc1 executable that terminates immediatley with the aforementioned error, when it's started without the "-m32" flag.
Also, with regards to "bad hardware": this is a multiprocessor server system that's in use every day, it's got numerous inbuilt hardware failure-detection mechanisms, so as soon as there's a CPU, memory or hard disk problem, the admin (me) gets notified immediatley. And there are clearly not any warnings at all. So, given all these self-tests (that even take almost ~5 minutes before the actual system really boots up) I should actually be able to be reasonably sure that this is no hardware problem at all. You said you were able to build it on i686-linux-gnu, was this also an SMP machine? I am really more than willing to take into consideration that this is a local (software) problem (i.e. due to parts of the GNU toolchain being outdated or whatever), nonetheless the previously mentioned google findings suggest that it isn't a totally isolated issue at all.
> No it does not. Are you sure you don't have some bad hardware? Just to summarize everything again: the "hardware" problem you anticipate would then vanish partially when providing the "-m32" switch to xgcc/cc1 directly (or by editing the Makefile)?
Subject: Re: New: possible problem: building gcc >= 4.2 on i686 GNU/Linux|SMP (non-64bit) platform fails On Tue, 12 Sep 2006, WISD00M at GMX dot NET wrote: > ./xgcc -B./ -B/usr/local/i686-pc-linux-gnu/bin/ -isystem > /usr/local/i686-pc-linux-gnu/include -isystem > /usr/local/i686-pc-linux-gnu/sys-include -L/root/gcc-build/gcc/../ld -O2 > -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes > -Wold-style-definition -isystem ./include -I. -I. > -I../../gcc-4.2-20060906/gcc -I../../gcc-4.2-20060906/gcc/. > -I../../gcc-4.2-20060906/gcc/../include > -I../../gcc-4.2-20060906/gcc/../libcpp/include > -I../../gcc-4.2-20060906/gcc/../libdecnumber -I../libdecnumber -g0 > -finhibit-size-directive -fno-inline-functions -fno-exceptions > -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-omit-frame-pointer \ > -c ../../gcc-4.2-20060906/gcc/crtstuff.c -DCRT_BEGIN \ > -o crtbegin.o If you rerun this manually with -v added to the compiler options, what is the full output? What are the contents of configargs.h in the gcc build directory?
Created attachment 12246 [details] the complete configargs.h file from the build gcc sub directory
I'm sorry, I obviously messed up the first translation unit that fails in my original posting (the error that I posted was already a later error, when I had adjusted the Makefile already). So, from a (FRESH) tarball extract, it's: ./xgcc -B./ -B/usr/local/i686-pc-linux-gnu/bin/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -L/root/tmp/plain/gcc/../ld -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../gcc-4.2-20060906/gcc -I../../gcc-4.2-20060906/gcc/. -I../../gcc-4.2-20060906/gcc/../include -I../../gcc-4.2-20060906/gcc/../libcpp/include -I../../gcc-4.2-20060906/gcc/../libdecnumber -I../libdecnumber -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-omit-frame-pointer \ -c ../../gcc-4.2-20060906/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o ../../gcc-4.2-20060906/gcc/crtstuff.c:1: sorry, unimplemented: 64-bit mode not compiled in make: *** [crtbegin.o] Error 1 Thus, I assume that you are mainly interested in seeing the verbose output of this (if you still want the output of the other one, just tell me), it's: Reading specs from ./specs Target: i686-pc-linux-gnu Configured with: ../gcc-4.2-20060906/configure Thread model: posix gcc version 4.2.0 20060906 (experimental) ./cc1 -quiet -v -I. -I. -I../../gcc-4.2-20060906/gcc -I../../gcc-4.2-20060906/gcc/. -I../../gcc-4.2-20060906/gcc/../include -I../../gcc-4.2-20060906/gcc/../libcpp/include -I../../gcc-4.2-20060906/gcc/../libdecnumber -I../libdecnumber -iprefix /root/tmp/plain/gcc/../lib/gcc/i686-pc-linux-gnu/4.2.0/ -isystem ./include -DIN_GCC -DCRT_BEGIN -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -isystem ./include ../../gcc-4.2-20060906/gcc/crtstuff.c -quiet -dumpbase crtstuff.c -mtune=generic -auxbase-strip crtbegin.o -g0 -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-omit-frame-pointer -o /tmp/ccwWA3rj.s ignoring duplicate directory "./include" ignoring nonexistent directory "/root/tmp/plain/gcc/../lib/gcc/i686-pc-linux-gnu/4.2.0/include" ignoring nonexistent directory "/root/tmp/plain/gcc/../lib/gcc/i686-pc-linux-gnu/4.2.0/../../../../i686-pc-linux-gnu/include" ignoring nonexistent directory "NONE/include" ignoring nonexistent directory "/usr/local/lib/gcc/i686-pc-linux-gnu/4.2.0/include" ignoring duplicate directory "/usr/local/lib/gcc/i686-pc-linux-gnu/../../../i686-pc-linux-gnu/include" ignoring duplicate directory "." ignoring duplicate directory "../../gcc-4.2-20060906/gcc/." #include "..." search starts here: #include <...> search starts here: . ../../gcc-4.2-20060906/gcc ../../gcc-4.2-20060906/gcc/../include ../../gcc-4.2-20060906/gcc/../libcpp/include ../../gcc-4.2-20060906/gcc/../libdecnumber ../libdecnumber ./include /usr/local/i686-pc-linux-gnu/include /usr/local/i686-pc-linux-gnu/sys-include /usr/local/include /usr/include End of search list. ../../gcc-4.2-20060906/gcc/crtstuff.c:1: sorry, unimplemented: 64-bit mode not compiled in GNU C version 4.2.0 20060906 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.0.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 0af382d0d476753fb032764518b91e16
Just for your info, when I now (again) MANUALLY ADD "-m32" to the parameter list, everything works again as expected: Reading specs from ./specs Target: i686-pc-linux-gnu Configured with: ../gcc-4.2-20060906/configure Thread model: posix gcc version 4.2.0 20060906 (experimental) ./cc1 -quiet -v -I. -I. -I../../gcc-4.2-20060906/gcc -I../../gcc-4.2-20060906/gcc/. -I../../gcc-4.2-20060906/gcc/../include -I../../gcc-4.2-20060906/gcc/../libcpp/include -I../../gcc-4.2-20060906/gcc/../libdecnumber -I../libdecnumber -iprefix /root/tmp/plain/gcc/../lib/gcc/i686-pc-linux-gnu/4.2.0/ -isystem ./include -DIN_GCC -DCRT_BEGIN -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -isystem ./include ../../gcc-4.2-20060906/gcc/crtstuff.c -quiet -dumpbase crtstuff.c -m32 -mtune=generic -auxbase-strip crtbegin.o -g0 -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-omit-frame-pointer -o /tmp/ccUA8Kid.s ignoring duplicate directory "./include" ignoring nonexistent directory "/root/tmp/plain/gcc/../lib/gcc/i686-pc-linux-gnu/4.2.0/include" ignoring nonexistent directory "/root/tmp/plain/gcc/../lib/gcc/i686-pc-linux-gnu/4.2.0/../../../../i686-pc-linux-gnu/include" ignoring nonexistent directory "NONE/include" ignoring nonexistent directory "/usr/local/lib/gcc/i686-pc-linux-gnu/4.2.0/include" ignoring duplicate directory "/usr/local/lib/gcc/i686-pc-linux-gnu/../../../i686-pc-linux-gnu/include" ignoring duplicate directory "." ignoring duplicate directory "../../gcc-4.2-20060906/gcc/." #include "..." search starts here: #include <...> search starts here: . ../../gcc-4.2-20060906/gcc ../../gcc-4.2-20060906/gcc/../include ../../gcc-4.2-20060906/gcc/../libcpp/include ../../gcc-4.2-20060906/gcc/../libdecnumber ../libdecnumber ./include /usr/local/i686-pc-linux-gnu/include /usr/local/i686-pc-linux-gnu/sys-include /usr/local/include /usr/include End of search list. GNU C version 4.2.0 20060906 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.0.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 0af382d0d476753fb032764518b91e16 ./as -V -Qy -o crtbegin.o /tmp/ccUA8Kid.s GNU assembler version 2.17 (i686-pc-linux-gnu) using BFD version 2.17
I only saw this with gcc plus the biarch patch. I have no problem with building gcc 4.2 on Linux/x86 SMP machines.
(In reply to comment #22) > I only saw this with gcc plus the biarch patch. what exactly is "this", could you be more specific? did you see the VERY SAME type of error/warnings while trying to build? and NO: this is an vanilla/unpatched gcc tarball obtained from a gcc mirror (md5sum: d2b9fc8e612a003be9d490b78b128ae9 gcc-core-4.2-20060906.tar.bz2) > I have no problem with building gcc 4.2 on Linux/x86 SMP machines. what is x86 in your case? i486,i586,i686,i786? what's your kernel version? The problem I encountered seems CURRENTLY specific to i686/SMP, at least this is where it's sort of documented that what I experienced here, happened before (see: http://www.gatago.com/gnu/gcc/help/24669804.html ) Also, trying a compilation of a fresh source tree using: export mytarget="i686-pc-linux-gnu" && ./configure --target=$mytarget --build=$mytarget --host=$mytarget did result in the same error, at the same point.
weird enough, when configuring target/host/build all set to "i586-pc-linux-gnu", the whole make process still cancels at the same point, even though the 64 bit stuff should theoretically not even be touched at all(?). thus, I currently assume that this is somehow related to undocumented/unchecked prerequisites/dependencies not being checked properly-so that gcc is attempted to built even though a dependency isn't satisfied, is there anywhere a list of minimum requirements for building gcc 4.2, so that I can check whether (and what) I should update if necessary?
Just for your info: I just tried to compile the two previous official releases on the same machine to troubleshoot this issue further (using no configure/make flags WHATSOEVER, building in a separate build directory in both cases): gcc 4.0.3 (347231730fb44b609b69226c3e432d80 gcc-core-4.0.3.tar.bz2) and gcc 4.1.0 (15efa164579c7cf4a48859ee87d2a1fa gcc-core-4.1.0.tar.bz2) (both obtained from gcc mirrors) While I did succeed compiling gcc 4.0.3 on the same machine (after however applying the patch mentioned in bug 27023 due to a too recent GNU make version), compiling gcc 4.1.0 DID indeed cancel at the same point as the two later releases did: /root/tmp/gcc-4.1.0/gcc-4.1.0-BUILD/./gcc/xgcc -B/root/tmp/gcc-4.1.0/gcc-4.1.0-BUILD/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../gcc-4.1.0/gcc -I../../gcc-4.1.0/gcc/. -I../../gcc-4.1.0/gcc/../include -I../../gcc-4.1.0/gcc/../libcpp/include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-pointer \ -c ../../gcc-4.1.0/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o ../../gcc-4.1.0/gcc/crtstuff.c:1: sorry, unimplemented: 64-bit mode not compiled in make[2]: *** [crtbegin.o] Error 1 make[2]: Leaving directory `/root/tmp/gcc-4.1.0/gcc-4.1.0-BUILD/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/root/tmp/gcc-4.1.0/gcc-4.1.0-BUILD' make: *** [all] Error 2 So, the cause for this really seems to have crept in somewhere in between 4.0.3 and 4.1.0, thus I ask anybody in the know: were there any additional dependencies (or default assumptions) introduced in either the underlying build system or alternatively the xgcc/cc1 files during that time line that could explain the behaviour I'm seeing here? Thanks for any further pointers
I have a dual Northwood with HT. I am running 2.6.9 kernel from RHEL 4 U4. Can you show me the output of # uname -a # cat /proc/cpuinfo
(In reply to comment #26) > # uname -a as previously mentioned (comment #9), it's: "Linux syssiphus 2.6.17.4 #1 SMP PREEMPT Mon Sep 11 14:42:28 CEST 2006 i686 unknown" > # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 5 model name : Pentium II (Deschutes) stepping : 3 cpu MHz : 450.080 cache size : 1024 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr bogomips : 901.73 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 5 model name : Pentium II (Deschutes) stepping : 3 cpu MHz : 450.080 cache size : 1024 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr bogomips : 900.09 processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 5 model name : Pentium II (Deschutes) stepping : 3 cpu MHz : 450.080 cache size : 1024 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr bogomips : 901.13 processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 5 model name : Pentium II (Deschutes) stepping : 3 cpu MHz : 450.080 cache size : 1024 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr bogomips : 902.21
Apparently, your target_flags sets MASK_64BIT. You need to run gdb on cc1 and set hardware watchpoint on target_flags to see where it sets MASK_64BIT: [hjl@gnu-3 gcc]$ touch x.i [hjl@gnu-3 gcc]$ gdb cc1 GNU gdb 6.4.50.20060406-cvs Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". Breakpoint 1 at 0x8138b96: file ../../gcc/diagnostic.c, line 602. Breakpoint 2 at 0x8138b43: file ../../gcc/diagnostic.c, line 547. Function "exit" not defined. Function "abort" not defined. (gdb) watch target_flags Hardware watchpoint 3: target_flags (gdb) r -fpreprocessed x.i -quiet -dumpbase x.i -mtune=pentiumpro -auxbase x -version -o x.s Starting program: /export/gnu/import/gcc-4.1.0/build/gcc/cc1 -fpreprocessed x.i -quiet -dumpbase x.i -mtune=pentiumpro -auxbase x -version -o x.s Hardware watchpoint 3: target_flags Hardware watchpoint 3: target_flags Hardware watchpoint 3: target_flags Old value = 0 New value = 8388808 decode_options (argc=12, argv=0xbff24ef4) at ../../gcc/opts.c:634 634 flag_unwind_tables = targetm.unwind_tables_default; (gdb) c Continuing. During symbol reading, incomplete CFI data; unspecified registers (e.g., eax) at 0x828dfc3. During symbol reading, incomplete CFI data; unspecified registers (e.g., ecx) at 0x828dfc3. During symbol reading, incomplete CFI data; unspecified registers (e.g., edx) at 0x828dfc3. During symbol reading, incomplete CFI data; unspecified registers (e.g., eax) at 0x830f53c. During symbol reading, incomplete CFI data; unspecified registers (e.g., ecx) at 0x830f53c. During symbol reading, incomplete CFI data; unspecified registers (e.g., edx) at 0x830f53c. Hardware watchpoint 3: target_flags Old value = 8388808 New value = 8405192 override_options () at ../../gcc/config/i386/i386.c:1614 1614 if (TARGET_SSEREGPARM (gdb) c Continuing. During symbol reading, incomplete CFI data; unspecified registers (e.g., eax) at 0x830f53c. During symbol reading, incomplete CFI data; unspecified registers (e.g., ecx) at 0x830f53c. During symbol reading, incomplete CFI data; unspecified registers (e.g., edx) at 0x830f53c. Hardware watchpoint 3: target_flags Old value = 8405192 New value = 8405208 override_options () at ../../gcc/config/i386/i386.c:1667 1667 if ((flag_unwind_tables || flag_asynchronous_unwind_tables (gdb) c Continuing. During symbol reading, incomplete CFI data; unspecified registers (e.g., eax) at 0x830f53c. During symbol reading, incomplete CFI data; unspecified registers (e.g., ecx) at 0x830f53c. During symbol reading, incomplete CFI data; unspecified registers (e.g., edx) at 0x830f53c. GNU C version 4.1.0 (i686-pc-linux-gnu) compiled by GNU C version 3.4.6 20060404 (Red Hat 3.4.6-3). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 2547d670e9349240a4187f725ff2e074 Program exited normally. (gdb)
This works for me and many many other people.
For the record, this was caused by obsolete awk version, please upgrade if you experience this problem. The need to document awk prerequisite is tracked in PR 30739.
Closing.