From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14476 invoked by alias); 8 Oct 2014 17:49:39 -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 14360 invoked by uid 55); 8 Oct 2014 17:49:32 -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: Wed, 08 Oct 2014 17: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/msg00613.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #26 from Jan Hubicka --- > 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. A I tried to explain, it is currently design decision to have one declaration and one symtam node for one symbol. The one decl rule was introduced by Codesourcery (Zack) in 2003-4. He updated frontends to avoid copying and dropped code that dealt with duplicated declarations. Due to lack of sanity checking some cases remained, like this one (because at that time we did not really have proper asm name hash). There are couple open PRs since that time that was never corrected. So either we need to fix remaining cases or revisit the decision and audit backend/middleend for duplicated decls. There are cases I know that would need updating - symbol equality folding - alias analysis - Symbol table allowing many to one mapping for symtab entries. I think it would be better to avoid duplicated entries in symbol table, so we will need way to associate all declarations with a given symbol. Probably ont that big deal except for updating code that deals with changing declaration associated with the node and we need to decide what declaration control symbol's visibility. Obviously if user provide two declarations, one is static and ohter public, we either want to error or do someting sane. - we need to produce errors when user defines two different symbols of same name (currently we produce invalid asm) - anchors - Zack dropped some code from dwarf2out - Visibility in varasm - those need to follow the main declaration. I had great fun fixing effects of this on AIX I definitly found the one decl scheme somewhat restrictive, but it also makes things easier and avoids weird bugs. We could revert this decision, but that is a project. Concerning Richards plan to annotate statements with warning strings, I think we could follow same scheme as EH regions and histograms does - i.e. have on side hash table annotating statements. For IPA I am trying to convince Martin Liska to introduce symtab annotation template for me that makes it easy to add data to a symbol that is removed/duplicated along with the symbol. Cgraph has the hook API for it, but convenient C++ wrap would be great. Here I think we want something similar and convert the existing EH/histograms to it. Honza