[Bug lto/40903] LTO doesn't merge common sections properly
--- 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=gccview=revrev=150365 Log: 2009-07-30 Richard Guenther rguent...@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
[Bug lto/40903] LTO doesn't merge common sections properly
--- 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=gccview=revrev=150262 Log: 2009-07-30 Richard Guenther rguent...@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
[Bug lto/40903] LTO doesn't merge common sections properly
--- 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
[Bug lto/40903] LTO doesn't merge common sections properly
--- 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
[Bug lto/40903] LTO doesn't merge common sections properly
--- 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|-00-00 00:00:00 |2009-07-29 13:39:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40903
[Bug lto/40903] LTO doesn't merge common sections properly
--- 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
[Bug lto/40903] LTO doesn't merge common sections properly
--- 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
[Bug lto/40903] LTO doesn't merge common sections properly
--- 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
[Bug lto/40903] LTO doesn't merge common sections properly
--- 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
[Bug lto/40903] LTO doesn't merge common sections properly
--- 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
