From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29982 invoked by alias); 8 Oct 2014 10:42:34 -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 29919 invoked by uid 55); 8 Oct 2014 10:42:31 -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 10:42: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/msg00564.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #25 from rguenther at suse dot de --- On Wed, 8 Oct 2014, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 > > --- Comment #24 from Jakub Jelinek --- > 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. Yes, I tried to fix things in this direction but failed (maybe didn't try hard enough). Basically I'd never merge decls in lto-symtab - tree merging already merges exactly equivalent function decls - but only fixup the cgraph for the tree merging that was done. Richard.