From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30969 invoked by alias); 7 Oct 2014 19:49:09 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 30904 invoked by uid 55); 7 Oct 2014 19:49:03 -0000 From: "hubicka at ucw dot cz" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2 Date: Tue, 07 Oct 2014 19:49:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Version: 4.9.1 X-Bugzilla-Keywords: diagnostic, lto, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: hubicka at ucw dot cz X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: hubicka at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.8.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-10/txt/msg00510.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #22 from Jan Hubicka --- 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