[Bug lto/43038] DECL_PRESERVE_P or attribute((used)) static globals not completely preserved with -flto

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038

--- Comment #12 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-03-02 10:16:12 UTC ---
(In reply to comment #11)
> > > The original LTO proposal included assembler changes to allow multiple 
> > > local symbols with the same name in the output.  You could resurrect that, 
> > > though allowing references to the multiple local symbols from asm imposes 
> > > extra requirements on what the assembler interface must look like 
> > > (directives to say which versions are being referred to by asms in a 
> > > particular part of the input?).
> 
> Hmm, doing that would imply need to refer to the static in some global way
> anyway. When it is referenced from regular code and two static variables from
> two different units might end up in the same instruction.
> Not too hard to implement I guess.
> > 
> > I think we settled on the idea to delay mangling of local symbols until after
> > we composed ltrans units (so we can also compose units in a way to avoid
> > the need to mangle local symbols with a used attribute).  It shouldn't be
> > too difficult to implement but sofar nobody has done the work (and it
> > will likely be easier with a global symbol table which we hopefully will
> > get for 4.7).
> 
> I do not like much the idea of improsing new artificial limits on the
> partitioning. Once we start doing fancy stuff at the ltrans time, we will
> have hard time partitioning the important stuff into single partition.  Those
> extra requirements would just make it harder
> 
> I probably like most the variant with extending the asm syntax for
> inputs/outputs at toplevel statements (like Sun compiler seems to do already)
> and declaring direct references to statics not LTO compatible.
> 
> It seems much cleaner to me to declare that variable is used at the place it is
> actually used rather than annotating the declaration. Also it avoid the need
> for asm statement to be aware of target mangling rules (i.e. prefixing with _)

Well we can still simply not mangle a static if it is marked used and
all conflicting decls are not used and also static.  Likewise not mangle
a static if there are no conflicts.  I consider this a QOI issue also
with regard to debugging.  This would be just delaying the mangling until
WPA stage (symbol merging), not ltrans stage.

It wouldn't fix the case with two conflicting used vars but it probably
would catch most real-world cases.

Richard.

> Honza