Re: varpool alias reorg

[Jan Hubicka <hubicka@ucw.cz>]

> > There are two problems here
> >   1) We do not stream builtin decls and merge them outside lto-symtab (by just
> >      streaming references to builtins with their asm names).  There is at least
> >      one extra PR related to this and on my TODO is to simply remove the code.
> >   2) Aliases within single unit works only when both the alias and the target use
> >      asm name.  This is because internally we store mangled DECL_ASSEMBLER_NAME and the
> >      alias_pair code.
> >      With LTO this breaks existing code simply because what used to be multiple units
> >      and thus safe is now single LTO unit.
> > 
> >      Dave Korn fixed part of the problem by introducing mangling code into lto-symtab
> >      His code solve similar problems with aliases from the asm code, but it
> >      did not solve the problem with aliases from LTO units, like here, simply
> >      because alias pair code bypass the lto-symtab.  One of goals of the incorrect patch
> >      above is to make lto-symtab to do the merging and thus fix this issue (for now at
> >      all decls except for builtins).
> > 
> >      Still it would be good to solve the problem on non-LTO compilation, too.
> >      We discussed introduction of proper symbol table into GCC at the GCC gathering last
> >      weekend.  It is where I am heading but it will take some time.
> > 
> > Until that happens, I suggest fixing the testcase same was as we already fixed
> > the memops-asm-lib.c in 4.6 timeframe.
> > 
> > Bootstrapped/regtested x86_64-linux, OK?
> 
> Ok.
Hi,
thanks!  Could you, please, also consider the second two variants I sent?  In
general attribute used is needed when implementing libfuncs since we never know
when folding will intoduce new libcall (like in memops-asm).  However this
particular case don't need use because the builtin is called directly.
They also solve the problem of BLOCK lists being messed up.

In meantime I tested both variants and they pass.  I will add a changelog, of course.

Honza