This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug lto/40903] LTO doesn't merge common sections properly
- From: "rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 29 Jul 2009 18:01:23 -0000
- Subject: [Bug lto/40903] LTO doesn't merge common sections properly
- References: <bug-40903-10053@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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