This is GCC Bugzilla

This is GCC Bugzilla Version 2.20+

Full Text Bug Listing

(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 an attachment (id=4191) [edit]
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 an attachment (id=4235) [edit]
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.