public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug lto/40903] New: LTO doesn't merge common sections properly
@ 2009-07-29 13:39 rguenth at gcc dot gnu dot org
2009-07-29 13:39 ` [Bug lto/40903] " rguenth at gcc dot gnu dot org
` (9 more replies)
0 siblings, 10 replies; 11+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-07-29 13:39 UTC (permalink / raw)
To: gcc-bugs
t1.c
double i;
t2.c
int i;
int main () { return i; }
should be accepted with -fcommon.
What needs to be done is that we have to keep a list of decls per symtab
entry that we might end up merging to and we need to return the proper
decl when looking up the canonical decl.
A warning is still appropriate here.
This happens in several SPEC 2000 and SPEC 2006 benchmarks.
--
Summary: LTO doesn't merge common sections properly
Product: gcc
Version: lto
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40903
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug lto/40903] LTO doesn't merge common sections properly
2009-07-29 13:39 [Bug lto/40903] New: LTO doesn't merge common sections properly rguenth at gcc dot gnu dot org
@ 2009-07-29 13:39 ` rguenth at gcc dot gnu dot org
2009-07-29 17:56 ` rth at gcc dot gnu dot org
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-07-29 13:39 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-29 13:39 -------
I'm working on this.
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2009-07-29 13:39:41
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40903
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug lto/40903] LTO doesn't merge common sections properly
2009-07-29 13:39 [Bug lto/40903] New: LTO doesn't merge common sections properly rguenth at gcc dot gnu dot org
2009-07-29 13:39 ` [Bug lto/40903] " rguenth at gcc dot gnu dot org
@ 2009-07-29 17:56 ` rth at gcc dot gnu dot org
2009-07-29 18:01 ` rguenther at suse dot de
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rth at gcc dot gnu dot org @ 2009-07-29 17:56 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from rth at gcc dot gnu dot org 2009-07-29 17:55 -------
I believe a "proper" way to handle this, preserving the semantics that
the linker provides, is to transform this into
union {
double _1;
int _2;
} i;
and replace occurrences with i._1, i._2, etc.
Perhaps a more interesting example to look at, besides the arguable
coding errors in SPEC, is the usages
core_cia.c:} saved_config __attribute((common));
core_t2.c:} t2_saved_config __attribute((common));
core_titan.c:} saved_config[4] __attribute__((common));
core_tsunami.c:} saved_config[2] __attribute__((common));
sys_sio.c:} saved_config __attribute((common));
in linux/arch/alpha/kernel/. Each usage is for a different hardware
type, and therefore mutually exclusive.
I believe there are Fortran common blocks that expect union-like
semantics as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40903
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug lto/40903] LTO doesn't merge common sections properly
2009-07-29 13:39 [Bug lto/40903] New: LTO doesn't merge common sections properly rguenth at gcc dot gnu dot org
2009-07-29 13:39 ` [Bug lto/40903] " rguenth at gcc dot gnu dot org
2009-07-29 17:56 ` rth at gcc dot gnu dot org
@ 2009-07-29 18:01 ` rguenther at suse dot de
2009-07-29 18:10 ` rth at gcc dot gnu dot org
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenther at suse dot de @ 2009-07-29 18:01 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from rguenther at suse dot de 2009-07-29 18:01 -------
Subject: Re: LTO doesn't merge common sections properly
On Wed, 29 Jul 2009, rth at gcc dot gnu dot org wrote:
> ------- Comment #2 from rth at gcc dot gnu dot org 2009-07-29 17:55 -------
> I believe a "proper" way to handle this, preserving the semantics that
> the linker provides, is to transform this into
>
> union {
> double _1;
> int _2;
> } i;
>
> and replace occurrences with i._1, i._2, etc.
That's another possibility. Though it would be only necessary if
you want to support punning between the entries.
Just keeping the decls and uses unmerged will get the exact same
effects as with non-LTO. Apart from that if there _are_ overlapping
uses those would be disambiguated by the alias-oracle and you'd
eventually get different behavior than from non-LTO mode (though
arguably the behavior is just undefined in that case).
Keeping the decls unmerged is certainly the less invasive approach.
> Perhaps a more interesting example to look at, besides the arguable
> coding errors in SPEC, is the usages
>
> core_cia.c:} saved_config __attribute((common));
> core_t2.c:} t2_saved_config __attribute((common));
> core_titan.c:} saved_config[4] __attribute__((common));
> core_tsunami.c:} saved_config[2] __attribute__((common));
> sys_sio.c:} saved_config __attribute((common));
>
> in linux/arch/alpha/kernel/. Each usage is for a different hardware
> type, and therefore mutually exclusive.
That should work indeed.
> I believe there are Fortran common blocks that expect union-like
> semantics as well.
Yes, they are marked as DECL_COMMON as well.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40903
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug lto/40903] LTO doesn't merge common sections properly
2009-07-29 13:39 [Bug lto/40903] New: LTO doesn't merge common sections properly rguenth at gcc dot gnu dot org
` (2 preceding siblings ...)
2009-07-29 18:01 ` rguenther at suse dot de
@ 2009-07-29 18:10 ` rth at gcc dot gnu dot org
2009-07-29 18:18 ` rguenther at suse dot de
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rth at gcc dot gnu dot org @ 2009-07-29 18:10 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from rth at gcc dot gnu dot org 2009-07-29 18:10 -------
So LTO still produces N output object files for N input files?
Cause you can't just output
.comm i,4,4
.comm i,8,8
in one object file, and I didn't see any changes to varasm.c...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40903
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug lto/40903] LTO doesn't merge common sections properly
2009-07-29 13:39 [Bug lto/40903] New: LTO doesn't merge common sections properly rguenth at gcc dot gnu dot org
` (3 preceding siblings ...)
2009-07-29 18:10 ` rth at gcc dot gnu dot org
@ 2009-07-29 18:18 ` rguenther at suse dot de
2009-07-29 19:20 ` rguenth at gcc dot gnu dot org
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenther at suse dot de @ 2009-07-29 18:18 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from rguenther at suse dot de 2009-07-29 18:18 -------
Subject: Re: LTO doesn't merge common sections properly
On Wed, 29 Jul 2009, rth at gcc dot gnu dot org wrote:
> ------- Comment #4 from rth at gcc dot gnu dot org 2009-07-29 18:10 -------
> So LTO still produces N output object files for N input files?
>
> Cause you can't just output
>
> .comm i,4,4
> .comm i,8,8
>
> in one object file, and I didn't see any changes to varasm.c...
Hm, it seems to output just the first decl, so depending on the
order of files on the commandline I either get
.comm i,4,4
or
.comm i,8,8
I have to check where that happens.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40903
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug lto/40903] LTO doesn't merge common sections properly
2009-07-29 13:39 [Bug lto/40903] New: LTO doesn't merge common sections properly rguenth at gcc dot gnu dot org
` (4 preceding siblings ...)
2009-07-29 18:18 ` rguenther at suse dot de
@ 2009-07-29 19:20 ` rguenth at gcc dot gnu dot org
2009-07-30 16:24 ` rguenth at gcc dot gnu dot org
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-07-29 19:20 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from rguenth at gcc dot gnu dot org 2009-07-29 19:20 -------
Ah, it's because I don't push to lto_global_var_decls. We can at
write-global-declarations time walk over all global vars and exchange the
written decl for
the largest in the chain.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40903
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug lto/40903] LTO doesn't merge common sections properly
2009-07-29 13:39 [Bug lto/40903] New: LTO doesn't merge common sections properly rguenth at gcc dot gnu dot org
` (5 preceding siblings ...)
2009-07-29 19:20 ` rguenth at gcc dot gnu dot org
@ 2009-07-30 16:24 ` rguenth at gcc dot gnu dot org
2009-07-30 16:25 ` rguenth at gcc dot gnu dot org
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-07-30 16:24 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from rguenth at gcc dot gnu dot org 2009-07-30 16:24 -------
Subject: Bug 40903
Author: rguenth
Date: Thu Jul 30 16:24:05 2009
New Revision: 150262
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150262
Log:
2009-07-30 Richard Guenther <rguenther@suse.de>
PR lto/40903
* lto-symtab.c (lto_symtab_compatible): Only warn for mismatched
types.
(lto_symtab_merge_decl): For decls we cannot merge chain them
appropriately in the symtab entry.
(lto_symtab_prevailing_decl): Return a matching entry from the
symtab chain.
* lto.c (read_cgraph_and_symbols): After fixing up decls choose
the largest decl for output and free TREE_CHAIN for further
use.
* gcc.dg/lto/20090729_0.c: New testcase.
* gcc.dg/lto/20090729_1.c: Likewise.
Added:
branches/lto/gcc/testsuite/gcc.dg/lto/20090729_0.c
branches/lto/gcc/testsuite/gcc.dg/lto/20090729_1.c
Modified:
branches/lto/gcc/ChangeLog.lto
branches/lto/gcc/lto-symtab.c
branches/lto/gcc/lto/ChangeLog
branches/lto/gcc/lto/lto.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40903
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug lto/40903] LTO doesn't merge common sections properly
2009-07-29 13:39 [Bug lto/40903] New: LTO doesn't merge common sections properly rguenth at gcc dot gnu dot org
` (7 preceding siblings ...)
2009-07-30 16:25 ` rguenth at gcc dot gnu dot org
@ 2009-07-30 16:25 ` rguenth at gcc dot gnu dot org
2009-08-03 8:46 ` rguenth at gcc dot gnu dot org
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-07-30 16:25 UTC (permalink / raw)
To: gcc-bugs
------- Comment #9 from rguenth at gcc dot gnu dot org 2009-07-30 16:25 -------
,
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40903
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug lto/40903] LTO doesn't merge common sections properly
2009-07-29 13:39 [Bug lto/40903] New: LTO doesn't merge common sections properly rguenth at gcc dot gnu dot org
` (6 preceding siblings ...)
2009-07-30 16:24 ` rguenth at gcc dot gnu dot org
@ 2009-07-30 16:25 ` rguenth at gcc dot gnu dot org
2009-07-30 16:25 ` rguenth at gcc dot gnu dot org
2009-08-03 8:46 ` rguenth at gcc dot gnu dot org
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-07-30 16:25 UTC (permalink / raw)
To: gcc-bugs
------- Comment #8 from rguenth at gcc dot gnu dot org 2009-07-30 16:24 -------
Fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40903
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug lto/40903] LTO doesn't merge common sections properly
2009-07-29 13:39 [Bug lto/40903] New: LTO doesn't merge common sections properly rguenth at gcc dot gnu dot org
` (8 preceding siblings ...)
2009-07-30 16:25 ` rguenth at gcc dot gnu dot org
@ 2009-08-03 8:46 ` rguenth at gcc dot gnu dot org
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-08-03 8:46 UTC (permalink / raw)
To: gcc-bugs
------- Comment #10 from rguenth at gcc dot gnu dot org 2009-08-03 08:46 -------
Subject: Bug 40903
Author: rguenth
Date: Mon Aug 3 08:45:37 2009
New Revision: 150365
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150365
Log:
2009-07-30 Richard Guenther <rguenther@suse.de>
PR lto/40903
* gcc.dg/lto/20090729_0.c: New testcase.
* gcc.dg/lto/20090729_1.c: Likewise.
Modified:
branches/lto/gcc/testsuite/ChangeLog.lto
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40903
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2009-08-03 8:46 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-07-29 13:39 [Bug lto/40903] New: LTO doesn't merge common sections properly rguenth at gcc dot gnu dot org
2009-07-29 13:39 ` [Bug lto/40903] " rguenth at gcc dot gnu dot org
2009-07-29 17:56 ` rth at gcc dot gnu dot org
2009-07-29 18:01 ` rguenther at suse dot de
2009-07-29 18:10 ` rth at gcc dot gnu dot org
2009-07-29 18:18 ` rguenther at suse dot de
2009-07-29 19:20 ` rguenth at gcc dot gnu dot org
2009-07-30 16:24 ` rguenth at gcc dot gnu dot org
2009-07-30 16:25 ` rguenth at gcc dot gnu dot org
2009-07-30 16:25 ` rguenth at gcc dot gnu dot org
2009-08-03 8:46 ` rguenth at gcc dot gnu dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).