[Bug lto/40903] LTO doesn't merge common sections properly

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.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