public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug other/29049]  New: possible problem: building gcc >= 4.2 on i686 GNU/Linux|SMP (non-64bit) platform fails
@ 2006-09-12 23:48 WISD00M at GMX dot NET
  2006-09-12 23:53 ` [Bug other/29049] " WISD00M at GMX dot NET
                   ` (30 more replies)
  0 siblings, 31 replies; 32+ messages in thread
From: WISD00M at GMX dot NET @ 2006-09-12 23:48 UTC (permalink / raw)
  To: gcc-bugs

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


^ permalink raw reply	[flat|nested] 32+ messages in thread
end of thread, other threads:[~2007-08-02  1:14 UTC | newest]

Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-09-12 23:48 [Bug other/29049] New: possible problem: building gcc >= 4.2 on i686 GNU/Linux|SMP (non-64bit) platform fails WISD00M at GMX dot NET
2006-09-12 23:53 ` [Bug other/29049] " WISD00M at GMX dot NET
2006-09-12 23:53 ` pinskia at gcc dot gnu dot org
2006-09-12 23:54 ` WISD00M at GMX dot NET
2006-09-12 23:54 ` WISD00M at GMX dot NET
2006-09-12 23:55 ` WISD00M at GMX dot NET
2006-09-12 23:56 ` WISD00M at GMX dot NET
2006-09-12 23:57 ` WISD00M at GMX dot NET
2006-09-12 23:58 ` WISD00M at GMX dot NET
2006-09-13  0:10 ` WISD00M at GMX dot NET
2006-09-13  0:12 ` WISD00M at GMX dot NET
2006-09-13  0:14 ` WISD00M at GMX dot NET
2006-09-13  0:24 ` WISD00M at GMX dot NET
2006-09-13  0:27 ` pinskia at gcc dot gnu dot org
2006-09-13  0:30 ` WISD00M at GMX dot NET
2006-09-13  0:36 ` WISD00M at GMX dot NET
2006-09-13  0:44 ` WISD00M at GMX dot NET
2006-09-13  0:51 ` WISD00M at GMX dot NET
2006-09-13  0:57 ` joseph at codesourcery dot com
2006-09-13  1:11 ` WISD00M at GMX dot NET
2006-09-13  1:11 ` WISD00M at GMX dot NET
2006-09-13  1:16 ` WISD00M at GMX dot NET
2006-09-13  2:56 ` hjl at lucon dot org
2006-09-13  3:16 ` WISD00M at GMX dot NET
2006-09-13  3:24 ` WISD00M at GMX dot NET
2006-09-13  5:02 ` WISD00M at GMX dot NET
2006-09-13  5:46 ` hjl at lucon dot org
2006-09-13  6:20 ` WISD00M at GMX dot NET
2006-09-13 15:03 ` hjl at lucon dot org
2006-10-24  8:19 ` pinskia at gcc dot gnu dot org
2007-08-02  1:14 ` lauras at gcc dot gnu dot org
2007-08-02  1:14 ` lauras at gcc dot gnu dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).