(resubmitting email sent to gcc-bugs through gnats) Hi, In trying to set up an environment for x86_64, I've run into the the error above in compiling the glibc (set for x86_64-unknown-linux crosscompile from i686-pc-linux-gnu host as suggested in the x86-64.org website). I have latest cvs sources from the gcc-3_3-branch. I've tracked the error down to being caused by the fact that the define HAVE_LD_RO_RW_SECTION_MIXING is being set to 1 by the configure scripts, and because of that the default_eh_frame_section function (in dwarf2out.c) is calling named_section_flags with flags that varasm.c doesn't like (because they differ from previous calls). I found that manually removing that HAVE_LD_RO_RW_SECTION_MIXING define causes everything to compile ok and intuitively it seems to me from the comments that that define shouldn't be set for the x86_64 tools, but I don't know enough about gcc to know that for sure. Anyone know what the proper fix for this would be? Here is the error line: /home/csd/dvl5/x86-64/bin/x86_64-unknown-linux-gcc soinit.c -c -O2 -Wall -Winlin e -Wstrict-prototypes -Wwrite-strings -g -fPIC -I../include -I. -I/home/csd /dvl5/glibc/build/elf -I.. -I../libio -I/home/csd/dvl5/glibc/build -I../sysdeps /x86_64/elf -I../linuxthreads/sysdeps/unix/sysv/linux/x86_64 -I../linuxthreads/s ysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread -I../sysdeps/pthread -I ../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix -I../linuxthrea ds/sysdeps/x86_64 -I../sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/lin ux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps /unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/x86_64 -I../sysdeps/unix -I. ./sysdeps/posix -I../sysdeps/x86_64/fpu -I../sysdeps/x86_64 -I../sysdeps/wordsiz e-64 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee7 54/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic - D_LIBC_REENTRANT -include ../include/libc-symbols.h -DPIC -DSHARED -o /home/c sd/dvl5/glibc/build/elf/soinit.os soinit.c:25: internal compiler error: in named_section_flags, at varasm.c:412 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions. I've attached a script which grabs binutils, gcc and glibc which I'm running when I hit this problem. I also just tried with the gcc-20030203 snapshot and the same happens thanks, csd Release: cvs gcc-3_3-branch Feb 3 checkout (and gcc-20030203 snapshot) Environment: linux i386 How-To-Repeat: run the getBuildAll script provided
From: Dara Hazeghi <dhazeghi@yahoo.com> To: gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org, csd_ob@daudt.org Cc: Subject: Re: target/9552: [x86-64] ICE in named_section_flags, at varasm.c Date: Wed, 14 May 2003 16:55:09 -0700 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit- trail&database=gcc&pr=9552 Hello, sorry this bug hasn't received feedback up until now. Still, when gcc say, "attach preprocessed source when appropriate", it means it. Would it be possible for you to check on current gcc 3.3 branch whether this problem still occurs, and if so, please send the .i file which is crashing the compiler, so other people can replicate the problem directly? Thanks, Dara
State-Changed-From-To: open->feedback State-Changed-Why: See Dara's question
I ran into the exact same bug in s390 with an x86 -> s390 gcc3.3. You can reproduce the problem in either of two ways: 1. (the just-the-one-file-that-ICEs way) s390-unknown-linux-gnu-gcc x.i (where x.i is the file I'm about to attach) - or - 2. (the real world way) wget http://www.kegel.com/crossgcc/crosstool-0.7.tar.gz tar -xzvf crosstool-0.7.tar.gz cd crosstool-0.7 eval `cat s390.dat` `cat gcc3.3-glibc2.3.2.dat` sh all.sh
Created attachment 4191 [details] preprocessed source causing gcc3.3 to crash
Received preprocessed source. Shouldn't be in WAITING now as Daniel points out.
Okay, I've confirmed the s390 bug. Since that's the only one we have preprocessed source for I'm changing the bug's summary to reflect that. Confirmed with gcc 3.3 branch and mainline (20030618). Also discovered that this bug does not occur with gcc 3.2, so this is a regression.
Created attachment 4235 [details] reduced testcase.i Dan actually did the work reducing this, he just forgot to cut out the unnecessary header stuff... Looks like this is a bug with __attribute__ ((section (".eh_frame")))
One problem here is that the test case is actually incorrect: it attempts to place a non-const global variable into a read-only .eh_frame section. Changing the test case to use static const char __EH_FRAME_BEGIN__[] makes the problem disappear. However, I guess that even so we should not ICE. This is not s390- related, however; the only s390-specific parts of this problem are that s390 by default enables generation of .eh_frame even for C, and that .eh_frame is read-only on s390. The latter property is shared by most platforms, while the former is only true for s390 and x86_64. To reproduce the problem on other platforms it should suffice to build with -fasynchronous-unwind-tables.
I can confirm this happens when building x86_64, as well.
Updated subject line; this is not s390-specific.
Postponed until GCC 3.3.2; this is invalid code.
*** Bug 10607 has been marked as a duplicate of this bug. ***
Postponed until GCC 3.3.3.
ICE on invalid code is most likely not going to be fixed for 3.3.3 so moving it to 3.4.
*** Bug 13586 has been marked as a duplicate of this bug. ***
This has been failing for a while and it is invalid code so move to 3.4.1 so it does not block the branching.
Move back the target for all regressions from 3.4.1 to 3.4.0, as required by our bug management policy.
I do not know why I reconfirmed this as x86_64 is fixed at least I can no longer reproduce the error.
Confirmed but the ICE is gone, so removing regression markers.
With gcc-3.4.0, at least, the ICE depends on the build system's toolchain! You can predict whether the ICE will occur by running with -S and grepping for eh_frame. The ICE occurs if the first eh_frame's w attribute disagrees with the const attribute of the __EH_FRAME_BEGIN__ in the test case. Here's the annoying part: with gcc-3.4.0, at least, the first eh_frame's 'w' attribute *seems to depend on the build system's binutils or glibc*! eh_frame has 'w' when gcc-3.4.0 is built on a system using gcc-3.3.3/glibc-2.1.3/binutils-2.14.90.0.5, and lacks the 'w' when built on a system using gcc-3.2.2/glibc-2.3.2/binutils-2.13.90.0.18. Thus one system's workaround (adding a 'const') seems to be another system's poison.
Looks like in gcc-3.4.0, gcc/gcc/configure.ac picks up the wrong ld for me, which probably leads to the wrong value being set for HAVE_LD_RO_RW_SECTION_MIXING. I haven't found the changeset that did it, but it could be neroden's change, http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/Attic/configure.in.diff?r1=1.645&r2=1.646 I'd be happy to provide a build log showing the wrong ld being found.
I suspect the 'found wrong ld' problem is mine somehow -- I was trying to do something vaguely canadian-crossy -- so it's probably not worth worrying about unless someone else runs into it.
> Looks like in gcc-3.4.0, gcc/gcc/configure.ac picks up the wrong ld for me, > which probably leads to the wrong value being set for > HAVE_LD_RO_RW_SECTION_MIXING. This problem also occurs when cross compiling freebsd 5.3 for 64 bit target on 32 bit freebsd host -- x86_64-unknown-freebsd5.3-gcc-3.4.2 running on 32-bit x86 freebsd 5.3, compiling a file in freebsd 5.3's fork of gcc (usr/src/contrib/gcc/crtstuff.c). The same cross compiler hosted on linux ia32 doesn't get the ICE. Stepping through the ICE I see named_section_eh_frame_section() going down the path which calls named_section_flags (EH_FRAME_SECTION_NAME, SECTION_WRITE); because HAVE_LD_RO_RW_SECTION_MIXING was not #defined. Per the earlier discussion, maybe if it had been #defined, the value of flags would get computed as 0. But flags is computed as a complex condition in the #ifdef HAVE_LD_RO_RW_SECTION_MIXING block. Does it necessarily match what default_section_type_flags comes up with?
The problem in my case was that during configuration of the cross gcc, the host linker was being picked for the capability test of HAVE_LD_RO_RW_SECTION_MIXING. ld is selected around the "in_tree_ld" part of configure. I had built the cross linker and provided it in PATH, but configure doesn't look there. Solution was to point "--with-ld" to the cross linker.
I can't reproduce this using the attached translation unit with an s390 cross-compiler for a i686 build/host. I tried adding the const qualifier as suggested in comment #8 but that didn't change anything. I'm not sure I understand correctly comment #20 and later as saying that the problem was due to the configuration of the reporter's compiler. In any case, since the bug hasn't been updated in over 10 years, I'm going to take the liberty of resolving it. Please feel free to reopen it if the problem can be reproduced (and if so, please provide steps to do it).