[Bug target/9552] [x86-64] ICE in named_section_flags, at varasm.c

[Bug target/9552] [x86-64] ICE in named_section_flags, at varasm.c

[dank@kegel.com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9552


dank@kegel.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dank@kegel.com


------- Additional Comments From dank@kegel.com  2003-06-10 06:18 -------
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

[Bug target/9552] [x86-64] ICE in named_section_flags, at varasm.c

[dhazeghi@yahoo.com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9552


dhazeghi@yahoo.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|dhazeghi@yahoo.com          |
             Status|WAITING                     |NEW
  GCC build triplet|                            |x86_64-unknown-linux-gnu
   GCC host triplet|                            |x86_64-unknown-linux-gnu
 GCC target triplet|                            |x86_64-unknown-linux-gnu
   Last reconfirmed|0000-00-00 00:00:00         |2003-06-12 00:38:49
               date|                            |
            Version|unknown                     |3.3


------- Additional Comments From dhazeghi@yahoo.com  2003-06-12 00:38 -------
Received preprocessed source. Shouldn't be in WAITING now as Daniel points out.

[Bug target/9552] [3.3/3.4 regression] [s390] ICE in named_section_flags, at varasm.c

[dhazeghi@yahoo.com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9552


dhazeghi@yahoo.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  GCC build triplet|x86_64-unknown-linux-gnu    |i686-linux-pc-gnu
   GCC host triplet|x86_64-unknown-linux-gnu    |i686-pc-linux-gnu
 GCC target triplet|x86_64-unknown-linux-gnu    |s390-unknown-linux-gnu
            Summary|[x86-64] ICE in             |[3.3/3.4 regression] [s390]
                   |named_section_flags, at     |ICE in named_section_flags,
                   |varasm.c                    |at varasm.c
   Target Milestone|---                         |3.3.1


------- Additional Comments From dhazeghi@yahoo.com  2003-06-17 17:07 -------
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.

[Bug target/9552] [3.3/3.4 regression] [s390] ICE in named_section_flags, at varasm.c

[uweigand at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9552



------- Additional Comments From uweigand at gcc dot gnu dot org  2003-06-18 16:26 -------
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.

[Bug target/9552] [3.3/3.4 regression] [s390] ICE in named_section_flags, at varasm.c

[dank at kegel dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9552



------- Additional Comments From dank at kegel dot com  2003-06-21 04:42 -------
I can confirm this happens when building x86_64, as well.

[Bug target/9552] [3.3/3.4 regression] ICE in named_section_flags, at varasm.c

[mmitchel at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9552


mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[3.3/3.4 regression] [s390] |[3.3/3.4 regression] ICE in
                   |ICE in named_section_flags, |named_section_flags, at
                   |at varasm.c                 |varasm.c


------- Additional Comments From mmitchel at gcc dot gnu dot org  2003-07-11 22:57 -------
Updated subject line; this is not s390-specific.

[Bug target/9552] [3.3/3.4 regression] ICE in named_section_flags, at varasm.c

[mmitchel at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9552


mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.3.1                       |3.3.2


------- Additional Comments From mmitchel at gcc dot gnu dot org  2003-07-15 16:50 -------
Postponed until GCC 3.3.2; this is invalid code.

[Bug target/9552] [3.3/3.4 regression] ICE in named_section_flags, at varasm.c

[pinskia at physics dot uc dot edu]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9552


pinskia at physics dot uc dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fvdl at wasabisystems dot
                   |                            |com


------- Additional Comments From pinskia at physics dot uc dot edu  2003-08-07 17:50 -------
*** Bug 10607 has been marked as a duplicate of this bug. ***

[Bug target/9552] [3.3/3.4 regression] ICE in named_section_flags, at varasm.c

[mmitchel at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9552


mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.3.2                       |3.3.3


------- Additional Comments From mmitchel at gcc dot gnu dot org  2003-10-16 02:41 -------
Postponed until GCC 3.3.3.

[Bug target/9552] [3.3/3.4 regression] ICE in named_section_flags, at varasm.c

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2003-12-25 00:26 -------
ICE on invalid code is most likely not going to be fixed for 3.3.3 so moving it to 3.4.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.3.3                       |3.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9552

[Bug target/9552] [3.3/3.4 regression] ICE in named_section_flags, at varasm.c

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9552

[Bug target/9552] [3.3/3.4 regression] ICE in named_section_flags, at varasm.c

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-01-06 18:05 -------
*** Bug 13586 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tnt at traffman dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9552

[Bug target/9552] [3.3/3.4 regression] ICE in named_section_flags, at varasm.c

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-01-11 00:08 -------
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.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4.0                       |3.4.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9552

[Bug target/9552] [3.3/3.4 regression] ICE in named_section_flags, at varasm.c

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2004-01-12 23:39 -------
Move back the target for all regressions from 3.4.1 to 3.4.0, as required by 
our bug management policy. 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4.1                       |3.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9552

[Bug target/9552] [3.3/3.4 regression] ICE in named_section_flags, at varasm.c

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-01-13 04:47 -------
I do not know why I reconfirmed this as x86_64 is fixed at least I can no longer reproduce 
the error.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9552

[Bug target/9552] accepts invalid code for attribute section

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-01-13 06:08 -------
Confirmed but the ICE is gone, so removing regression markers.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|ice-on-invalid-code         |accepts-invalid
            Summary|[3.3/3.4 regression] ICE in |accepts invalid code for
                   |named_section_flags, at     |attribute section
                   |varasm.c                    |
   Target Milestone|3.4.0                       |---


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9552

[Bug target/9552] accepts invalid code for attribute section

[dank at kegel dot com]

------- Additional Comments From dank at kegel dot com  2004-05-10 21:09 -------
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.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9552

[Bug target/9552] accepts invalid code for attribute section

[dank at kegel dot com]

------- Additional Comments From dank at kegel dot com  2004-05-10 22:08 -------
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.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |neroden at twcny dot rr dot
                   |                            |com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9552

[Bug target/9552] accepts invalid code for attribute section

[dank at kegel dot com]

------- Additional Comments From dank at kegel dot com  2004-05-11 01:11 -------
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.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9552

[Bug target/9552] accepts invalid code for attribute section

[nomura at netapp dot com]

------- Comment #23 from nomura at netapp dot com  2006-02-17 23:58 -------
> 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?


-- 

nomura at netapp dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nomura at netapp dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9552

[Bug target/9552] accepts invalid code for attribute section

[nomura at netapp dot com]

------- Comment #24 from nomura at netapp dot com  2006-02-18 02:30 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9552