[Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2

["hubicka at ucw dot cz" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886

--- Comment #26 from Jan Hubicka <hubicka at ucw dot cz> ---
> But is warning/error attribute the only thing on aliases that can hold extra
> semantics info (now or in the future)?  I'd say LTO symtab merging should merge
> what is mergeable, and should leave leave as separate decls with the same
> asm-name what holds non-mergeable semantics on it.
> Say, if you declare some function (or different, just with same asm name) with
> warning attribute in one TU, with error attribute in another TU and without it
> on another TU, IMHO those three decls shouldn't be merged together, you should
> note in cgraph that you have aliases that have the same asm name but different
> semantics and just ensure that you use the right cgraph nodes and decls in the
> corresponding callers.

A I tried to explain, it is currently design decision to have  one declaration
and one symtam node for one symbol.  The one decl rule was introduced by
Codesourcery (Zack) in 2003-4. He updated frontends to avoid copying and
dropped code that dealt with duplicated declarations.  Due to lack of sanity
checking some cases remained, like this one (because at that time we did not
really have proper asm name hash).  There are couple open PRs since that time
that was never corrected.

So either we need to fix remaining cases or revisit the decision and audit
backend/middleend for duplicated decls.  There are cases I know that would need
updating
 - symbol equality folding
 - alias analysis
 - Symbol table allowing many to one mapping for symtab entries.
   I think it would be better to avoid duplicated entries in symbol table,
   so we will need way to associate all declarations with a given symbol.
   Probably ont that big deal except for updating code that deals with 
   changing declaration associated with the node and we need to decide what
   declaration control symbol's visibility. 

   Obviously if user provide two declarations, one is static and ohter public,
   we either want to error or do someting sane.
 - we need to produce errors when user defines two different symbols of same
name
   (currently we produce invalid asm)
 - anchors
 - Zack dropped some code from dwarf2out
 - Visibility in varasm - those need to follow the main declaration.  I had
great
   fun fixing effects of this on AIX

I definitly found the one decl scheme somewhat restrictive, but it also makes
things easier and avoids weird bugs. We could revert this decision, but that is
a project.

Concerning Richards plan to annotate statements with warning strings, I think
we could follow same scheme as EH regions and histograms does - i.e. have on
side hash table annotating statements.

For IPA I am trying to convince Martin Liska to introduce symtab annotation
template
for me that makes it easy to add data to a symbol that is removed/duplicated
along with
the symbol.  Cgraph has the hook API for it, but convenient C++ wrap would be
great.

Here I think we want something similar and convert the existing EH/histograms
to it.

Honza