This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV
- From: "rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 24 Aug 2017 15:16:21 +0000
- Subject: [Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV
- Auto-submitted: auto-generated
- References: <bug-81968-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
--- Comment #1 from rguenther at suse dot de <rguenther at suse dot de> ---
On August 24, 2017 4:18:45 PM GMT+02:00, "ro at gcc dot gnu.org"
<gcc-bugzilla@gcc.gnu.org> wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
>
> Bug ID: 81968
> Summary: [8 regression] early lto debug objects make Solaris ld
> SEGV
> Product: gcc
> Version: 8.0
> Status: UNCONFIRMED
> Severity: normal
> Priority: P3
> Component: lto
> Assignee: unassigned at gcc dot gnu.org
> Reporter: ro at gcc dot gnu.org
> CC: marxin at gcc dot gnu.org, rguenth at gcc dot gnu.org
> Target Milestone: ---
> Target: *-*-solaris2.11
>
>The Early LTO Debug patches caused a large number of testsuite
>regressions on
>Solaris when using /bin/ld:
>
>+UNRESOLVED: g++.dg/lto/20101010-4
>cp_lto_20101010-4_0.o-cp_lto_20101010-4_0.o
>execute -std=c++0x -flto -g -r -nostdlib
>+FAIL: g++.dg/lto/20101010-4
>cp_lto_20101010-4_0.o-cp_lto_20101010-4_0.o link,
>-std=c++0x -flto -g -r -nostdlib
>
>They all are like
>
>FAIL: c-c++-common/cilk-plus/CK/cilk-for-2.c -O3 -flto -g (test for
>excess
>errors)
>Excess errors:
>collect2: fatal error: ld terminated with signal 11 [Segmentation
>Fault]
>compilation terminated.
>ld: warning: file /var/tmp//ccOFDEXadebugobjtem: section [1] has
>invalid type [
>SHT_NULL ]
>ld: warning: file /var/tmp//ccOFDEXadebugobjtem: section [5] contains
>both
>SHF_EXCLUDE and SHF_ALLOC flags: SHF_EXCLUDE ignored
>
>The same problem happens when gcc is configured to use gas and ld
>instead of
>as/ld, sparc and x86, 32 and 64-bit.
>
>Clearly a SEGV isn't the best error handling, and I'm not yet certain
>if the
>errors
>are benign. OTOH, I don't yet know why the objects are created this
>way.
They are created that way to make my life easier. They are supposed to be valid
ELF objects and they are according to the specs and my interpretation.
>
> Rainer