Bug 9552 - accepts invalid code for attribute section
Summary: accepts invalid code for attribute section
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 3.3
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: accepts-invalid
: 10607 13586 (view as bug list)
Depends on:
Reported: 2003-02-03 19:16 UTC by csd_ob
Modified: 2016-03-08 22:24 UTC (History)
9 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: s390-*-linux-gnu, x86_64-*-linux-gnu
Build: i686-linux-pc-gnu
Known to work:
Known to fail:
Last reconfirmed: 2005-09-24 17:06:54

attachments (9.07 KB, application/octet-stream)
2003-05-21 15:17 UTC, csd_ob
preprocessed source causing gcc3.3 to crash (4.91 KB, text/plain)
2003-06-10 06:19 UTC, dank
reduced testcase.i (154 bytes, text/plain)
2003-06-17 17:14 UTC, Dara Hazeghi

Note You need to log in before you can comment on or make changes to this bug.
Description csd_ob 2003-02-03 19:16:01 UTC
(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)

linux i386

run the getBuildAll script provided
Comment 1 Dara Hazeghi 2003-05-14 16:55:09 UTC
From: Dara Hazeghi <dhazeghi@yahoo.com>
To: gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org, csd_ob@daudt.org
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  
 directly? Thanks,
Comment 2 Wolfgang Bangerth 2003-05-15 04:37:11 UTC
State-Changed-From-To: open->feedback
State-Changed-Why: See Dara's question
Comment 3 dank 2003-06-10 06:18:24 UTC
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
Comment 4 dank 2003-06-10 06:19:26 UTC
Created attachment 4191 [details]
preprocessed source causing gcc3.3 to crash
Comment 5 Dara Hazeghi 2003-06-12 00:38:49 UTC
Received preprocessed source. Shouldn't be in WAITING now as Daniel points out.
Comment 6 Dara Hazeghi 2003-06-17 17:07:55 UTC
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.
Comment 7 Dara Hazeghi 2003-06-17 17:14:18 UTC
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")))
Comment 8 Ulrich Weigand 2003-06-18 16:26:04 UTC
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.

Comment 9 dank 2003-06-21 04:42:52 UTC
I can confirm this happens when building x86_64, as well.
Comment 10 Mark Mitchell 2003-07-11 22:57:37 UTC
Updated subject line; this is not s390-specific.
Comment 11 Mark Mitchell 2003-07-15 16:50:38 UTC
Postponed until GCC 3.3.2; this is invalid code.
Comment 12 Andrew Pinski 2003-08-07 17:50:28 UTC
*** Bug 10607 has been marked as a duplicate of this bug. ***
Comment 13 Mark Mitchell 2003-10-16 02:41:45 UTC
Postponed until GCC 3.3.3.
Comment 14 Andrew Pinski 2003-12-25 00:26:31 UTC
ICE on invalid code is most likely not going to be fixed for 3.3.3 so moving it to 3.4.
Comment 15 Andrew Pinski 2004-01-06 18:05:43 UTC
*** Bug 13586 has been marked as a duplicate of this bug. ***
Comment 16 Andrew Pinski 2004-01-11 00:08:58 UTC
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.
Comment 17 Steven Bosscher 2004-01-12 23:39:38 UTC
Move back the target for all regressions from 3.4.1 to 3.4.0, as required by 
our bug management policy. 
Comment 18 Andrew Pinski 2004-01-13 04:47:47 UTC
I do not know why I reconfirmed this as x86_64 is fixed at least I can no longer reproduce 
the error.
Comment 19 Andrew Pinski 2004-01-13 06:08:39 UTC
Confirmed but the ICE is gone, so removing regression markers.
Comment 20 dank 2004-05-10 21:09:05 UTC
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-, 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.
Comment 21 dank 2004-05-10 22:08:28 UTC
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.
Comment 22 dank 2004-05-11 01:11:30 UTC
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.
Comment 23 nomura 2006-02-17 23:58:50 UTC
> 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?
Comment 24 nomura 2006-02-18 02:30:55 UTC
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.
Comment 25 Martin Sebor 2016-03-08 22:24:30 UTC
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).