From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8882 invoked by alias); 12 Sep 2006 23:48:48 -0000 Received: (qmail 8837 invoked by uid 48); 12 Sep 2006 23:48:38 -0000 Date: Tue, 12 Sep 2006 23:48:00 -0000 Subject: [Bug other/29049] New: possible problem: building gcc >= 4.2 on i686 GNU/Linux|SMP (non-64bit) platform fails X-Bugzilla-Reason: CC Message-ID: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "WISD00M at GMX dot NET" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-09/txt/msg01106.txt.bz2 List-Id: 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. -- Summary: possible problem: building gcc >= 4.2 on i686 GNU/Linux|SMP (non-64bit) platform fails Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: WISD00M at GMX dot NET GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29049