Bug 49665 - 'defined in discarded section' link failures on cpu2006 benchmarks
Summary: 'defined in discarded section' link failures on cpu2006 benchmarks
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: other (show other bugs)
Version: 4.7.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-06 23:47 UTC by Pat Haugen
Modified: 2011-09-13 16:10 UTC (History)
5 users (show)

See Also:
Host: powerpc64-linux
Target: powerpc64-linux
Build: powerpc64-linux
Known to work:
Known to fail:
Last reconfirmed: 2011-07-07 06:51:19


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pat Haugen 2011-07-06 23:47:44 UTC
450.soplex (-O2) and 471.omnetpp fail to link in 64-bit mode with the same error.

450.soplex:

`soplex::SPxBasis::~SPxBasis()' referenced in section `.data.rel.ro._ZTVN6soplex8SPxBasisE[vtable for soplex::SPxBasis]' of spxbasis.o: defined in discarded section `.group' of spxbasis.o
`soplex::SPxLP::~SPxLP()' referenced in section `.data.rel.ro._ZTVN6soplex5SPxLPE[vtable for soplex::SPxLP]' of spxlp.o: defined in discarded section `.group' of spxlp.o
`soplex::LPRowSet::~LPRowSet()' referenced in section `.text' of spxlpfread.o: defined in discarded section `.group' of spxlpfread.o
`soplex::LPRowSet::~LPRowSet()' referenced in section `.text' of spxlpfread.o: defined in discarded section `.group' of spxlpfread.o


471.omnetpp:

`cEqdHistogramBase::~cEqdHistogramBase()' referenced in section `.data.rel.ro._ZTV17cEqdHistogramBase[vtable for cEqdHistogramBase]' of libs/sim/std/netpack.o: defined in discarded section `.group' of libs/sim/std/netpack.o
Comment 1 Alan Modra 2011-07-07 06:51:19 UTC
There are some really weird things going on here that make me think this is a linker bug rather than a gcc bug.  Assigning to myself to save others wasting time on the PR.
Comment 2 Alan Modra 2011-07-07 09:50:54 UTC
So, looks like a gcc bug after all.  There are four files with a certain group
example.s:	.section	.text._ZN6soplex8SPxBasisD2Ev,"axG",@progbits,_ZN6soplex8SPxBasisD5Ev,comdat
example.s:	.section	.text._ZN6soplex8SPxBasisD0Ev,"axG",@progbits,_ZN6soplex8SPxBasisD5Ev,comdat
soplex.s:	.section	.text._ZN6soplex8SPxBasisD2Ev,"axG",@progbits,_ZN6soplex8SPxBasisD5Ev,comdat
soplex.s:	.section	.text._ZN6soplex8SPxBasisD0Ev,"axG",@progbits,_ZN6soplex8SPxBasisD5Ev,comdat
spxbasis.s:	.section	.text._ZN6soplex8SPxBasisD2Ev,"axG",@progbits,_ZN6soplex8SPxBasisD5Ev,comdat
spxbasis.s:	.section	.text._ZN6soplex8SPxBasisD0Ev,"axG",@progbits,_ZN6soplex8SPxBasisD5Ev,comdat
spxsolver.s:	.section	.text._ZN6soplex8SPxBasisD2Ev,"axG",@progbits,_ZN6soplex8SPxBasisD5Ev,comdat
spxsolver.s:	.section	.text._ZN6soplex8SPxBasisD0Ev,"axG",@progbits,_ZN6soplex8SPxBasisD5Ev,comdat

In each of these files this group contains two sections, with the code for _ZN6soplex8SPxBasisD0Ev and _ZN6soplex8SPxBasisD2Ev in them.  In just one file, spsbasis.o, there is an alias for _ZN6soplex8SPxBasisD2Ev.

	.weak	_ZN6soplex8SPxBasisD1Ev
	.set	_ZN6soplex8SPxBasisD1Ev,_ZN6soplex8SPxBasisD2Ev

When the group in spsbasis.o is dropped, _ZN6soplex8SPxBasisD1Ev has no proper definition.
Comment 3 Andrew Pinski 2011-07-07 17:41:24 UTC
> In each of these files this group contains two sections, with the code for
> _ZN6soplex8SPxBasisD0Ev and _ZN6soplex8SPxBasisD2Ev in them.  In just one file,
> spsbasis.o, there is an alias for _ZN6soplex8SPxBasisD2Ev.

Hmm, if there is an set in one of the files but not the others, then there is something wrong in general.  Is the code violating ODR?
Comment 4 Markus Trippelsdorf 2011-07-09 19:47:15 UTC
This looks like a dup of bug 49538 that just got fixed 
by a recent commit of Jason:


commit dabebf7ecc90b59b0603d2428cf465fe1f0d642b
Author: jason <jason@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Sat Jul 9 03:33:44 2011 +0000

    gcc/
        * cgraph.c (cgraph_add_to_same_comdat_group): New.
        * cgraph.h: Declare it.
        * ipa.c (function_and_variable_visibility): Make sure thunks
        have the right visibility.
    gcc/cp/
        * method.c (use_thunk): Use cgraph_add_to_same_comdat_group.
        * optimize.c (maybe_clone_body): Likewise.
        * semantics.c (maybe_add_lambda_conv_op): Likewise.

    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@176071
Comment 5 Pat Haugen 2011-07-10 18:43:28 UTC
The problems still exist in r176125, although looks like a couple from soplex went away but a couple new ones for omnetpp showed up.


soplex:

`soplex::SPxBasis::~SPxBasis()' referenced in section `.data.rel.ro._ZTVN6soplex8SPxBasisE[vtable for soplex::SPxBasis]' of spxbasis.o: defined in discarded
 section `.group' of spxbasis.o
`soplex::SPxLP::~SPxLP()' referenced in section `.data.rel.ro._ZTVN6soplex5SPxLPE[vtable for soplex::SPxLP]' of spxlp.o: defined in discarded section `.grou
p' of spxlp.o


omnetpp:

`cStdDev::~cStdDev()' referenced in section `.data.rel.ro._ZTV7cStdDev[vtable for cStdDev]' of libs/sim/cstat.o: defined in discarded section `.group' of libs/sim/cstat.o
`cStatistic::~cStatistic()' referenced in section `.data.rel.ro._ZTV10cStatistic[vtable for cStatistic]' of libs/sim/std/netpack.o: defined in discarded section `.group' of libs/sim/std/netpack.o
`cEqdHistogramBase::~cEqdHistogramBase()' referenced in section `.data.rel.ro._ZTV17cEqdHistogramBase[vtable for cEqdHistogramBase]' of libs/sim/std/netpack.o: defined in discarded section `.group' of libs/sim/std/netpack.o
Comment 6 Markus Trippelsdorf 2011-07-10 19:08:14 UTC
Another thing you might check is to revert the commit
pointed out here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49533#c5
and see if this makes any difference.
Comment 7 Pat Haugen 2011-07-14 17:19:10 UTC
Yes, if I remove the patch for r174989 then both benchmarks build without error.
Comment 8 Jan Hubicka 2011-09-13 14:56:55 UTC
Can you, please, check that the bug is fixed now?
Comment 9 Pat Haugen 2011-09-13 16:10:47 UTC
Yes, this is fixed with your patches for pr49533.

Thanks.