(resubmitting email sent to gcc-bugs through gnats)
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
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
cvs gcc-3_3-branch Feb 3 checkout (and gcc-20030203 snapshot)
run the getBuildAll script provided
From: Dara Hazeghi <firstname.lastname@example.org>
To: email@example.com, firstname.lastname@example.org, email@example.com
Subject: Re: target/9552: [x86-64] ICE in named_section_flags, at varasm.c
Date: Wed, 14 May 2003 16:55:09 -0700
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
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)
(where x.i is the file I'm about to attach)
- or -
2. (the real world way)
tar -xzvf crosstool-0.7.tar.gz
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]
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__
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
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-22.214.171.124.5, and lacks the 'w'
when built on a system using
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,
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
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).