From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6836 invoked by alias); 8 Oct 2014 07:37:00 -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 6760 invoked by uid 55); 8 Oct 2014 07:36:54 -0000 From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2 Date: Wed, 08 Oct 2014 07:37: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: rguenther at suse dot de 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/msg00538.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #23 from rguenther at suse dot de --- On Tue, 7 Oct 2014, hubicka at ucw dot cz wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 > > --- Comment #22 from Jan Hubicka --- > We can also put warning attribute into gimple call. I like that better. We can easily add a GF_CALL_WARN / GF_CALL_ERROR flag, but the question is where to put the warning string... the issue with this bugreport is that it might not be on the decl (because the decl is now replaced with one with/without the attribute). Maybe if we always "merge" the warning attributes then the call flag tells us whether to ignore it or not ... Thus for this particular bug (bogus warning) just adding the flag as a requirement to emit the warning/error would be enough. We may still lose warnings/errors if the wrong decl is picked for a GF_CALL_WARN call though. Yeah, now the idea of adding a generic annotation pointer to gimple stmts will pop up again ... of course I don't like that very much. OTOH we had the idea of avoiding warnings from the middle-end for dead code by queuing warnings to emit on stmts and only emit them if the stmt is still live at a certain point during the compilation. All that said - what about going with the simple GF_CALL_WARN_OR_ERROR flag to avoid the false "positives"?