From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77242 invoked by alias); 25 Mar 2015 12:59:29 -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 77162 invoked by uid 48); 25 Mar 2015 12:59:23 -0000 From: "manu at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/65536] LTO line number information garbled Date: Wed, 25 Mar 2015 13:30: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: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: manu at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-03/txt/msg02743.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D65536 --- Comment #34 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez --- (In reply to Martin Li=C5=A1ka from comment #30) > Created attachment 35132 [details] > Chrome: ODR warnings with patch from #c21 @Martin: The previous comment where the ICE is mentioned seems to refer to Jan's lat= est patch (with the cache), but this comment appears to refer to my patch in comment 21. Is that right?=20 I don't see how you can get that backtrace with Jan's patch: linemap_line_s= tart should only be called when applying the location cache, no? @Jan: I think: + linemap_line_start (line_table, loc.line, + MAX (81, loc.col + 1)) should simply be: + linemap_line_start (line_table, loc.line, + max + 1) For what is worth, I think your patch should already help a lot in GCC 5, it seems a move in the right direction. Perhaps the WPA sorting time is offset= by the memory savings and lower number of maps, which should reduce lookup tim= es. It would really be interesting to compute the sum of dump_line_table_statistics() for each input file before stream out and for = the LTO line_table after stream in. It will give you some idea of how much you = can expect to save in streamed out data and LTO memory by streaming out the line_tables directly. >>From gcc-bugs-return-481600-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Mar 25 13:14:33 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 111180 invoked by alias); 25 Mar 2015 13:14:33 -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 Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 105548 invoked by uid 48); 25 Mar 2015 13:14:24 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression Date: Wed, 25 Mar 2015 13:33:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ipa X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.0 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: 2015-03/txt/msg02744.txt.bz2 Content-length: 2012 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076 --- Comment #19 from Richard Biener --- I've meanwhile disabled pass_chkp_instrumentation_passes by default. The fixup_cfg in pass_build_ssa_passes doesn't do anything on tramp3d (and bootstrap/testing shows no issue removing it either). Adding a local_pure_const to the end of build_ssa_passes unfortunately makes us ICE in cgraph node verification during early inlining (we have a dangling call-stmt without a BB on a cgraph edge). Not sure how that happens as we fixup the cfg and rebuild cgraph edges before early inlining. Looks like re-building cgraph edges fixes that. This brings down the number of clobbers and stmts to 4.9 level. Index: gcc/passes.def =================================================================== --- gcc/passes.def (revision 221660) +++ gcc/passes.def (working copy) @@ -54,10 +54,12 @@ along with GCC; see the file COPYING3. NEXT_PASS (pass_build_ssa_passes); PUSH_INSERT_PASSES_WITHIN (pass_build_ssa_passes) NEXT_PASS (pass_fixup_cfg); + NEXT_PASS (pass_rebuild_cgraph_edges); NEXT_PASS (pass_init_datastructures); NEXT_PASS (pass_build_ssa); NEXT_PASS (pass_ubsan); NEXT_PASS (pass_early_warn_uninitialized); + NEXT_PASS (pass_local_pure_const); POP_INSERT_PASSES () NEXT_PASS (pass_chkp_instrumentation_passes); as opposed to the also possible patch (which doesn't change anything but compile-time): Index: gcc/passes.def =================================================================== --- gcc/passes.def (revision 221657) +++ gcc/passes.def (working copy) @@ -53,7 +53,6 @@ along with GCC; see the file COPYING3. NEXT_PASS (pass_ipa_chkp_early_produce_thunks); NEXT_PASS (pass_build_ssa_passes); PUSH_INSERT_PASSES_WITHIN (pass_build_ssa_passes) - NEXT_PASS (pass_fixup_cfg); NEXT_PASS (pass_init_datastructures); NEXT_PASS (pass_build_ssa); NEXT_PASS (pass_ubsan);