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

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

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

--- Comment #22 from Jan Hubicka <hubicka at ucw dot cz> ---
Concerning Richard's comment, it is true that we will produce more warings then
before in case function is optimized out.  But we always did produce extra
warnings
when the function call is optimized out (as dead or pure/const unused) during
RTL optimization. Of course this was more common before we got tree-ssa, but
the
feature AFAIK predates that.

This is ugly area, because it exposes too much of internals.

> The only duplicate decls are the C extern inline __attribute__((gnu_inline))
> (or -std=c89/gnu89 extern inline) or C++ inline __attribute__((gnu_inline)).
> We do have a middle-end representation of those, don't we?

We don't.  We really replace inline version by offline and mark it noinline.
With Winline you get warning "redefined extern inline functions are not
considered for inlining"
Here I think a way around would be to make C/C++ FEs to produce a static inline
function
and record in its cgraph node that it should be used for inlining of some other
symbol.
Unreachable code removal would need to be extended to deal with this (i.e. not
remove it until
references to the real symbol disappears) and inliner can handle it easily
redirecting
to the inline version prior inlining.

I never got past implementing the frontend part though.

> Do you have a problem that they have the same asm names, or DECL_NAME,
> something else?

Asm name, since Zack's one declaration changes, we are supposed to have only
one
decl for an ASM name.  It is not always true - the warning attribute is one
offender
and in some cases FEs still break the rule.

> If you wanted different asm names (e.g. normal asm name plus space at the end),
> we'd need some code to change calls to the functions with space after it back
> into ones without it if inlining failed.

This still does break one declaration rule because we would end up with two
declarations and two symbols for one real symbol.  This cause problems, because
we need to consider this i.e. in testing symbols for equality etc.

We do have a precedent here - the weakrefs are the same evil.  I could
generalize
weakref code to also handle warnings(), pattern match this sepcific use (where
we have two symbols for one asm name that differs by warnings), keep the
non-warning
global, turn the warning decl static "weakref" translating into the global
decl.
Making it static is needed to support different warning messsages across
multiple
LTO units - we must not merge the warning annotated symbols.

Now of course this will need a lot of extra special casing of "weakref" because
currently we belive the visibility properties of the duplicated decl that does
not match the visibility properties of the real node.
For weakref I just redirect all refernces to the prevailing declaration if it
exists
that solves the problem.  This would disable the warnings.

So while I can implement this, it is not bacportable to 4.8/4.9 and it will
likely
trigger interesting side cases for a while, like weakref did.

We can also put warning attribute into gimple call.

Honza