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
