From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 92346 invoked by alias); 24 Mar 2015 19:37:52 -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 92258 invoked by uid 48); 24 Mar 2015 19:37:45 -0000 From: "manu at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/65536] LTO line number information garbled Date: Tue, 24 Mar 2015 19:58: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/msg02645.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D65536 --- Comment #22 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez --- (In reply to Jan Hubicka from comment #20) > It seems that manuel just commented out the actual insertion to linemap, > columns are still streamed and ignored. >=20 > Doing so will clearly make ODR waring more difficult to follow, so perhaps > we could try to go for it only after reading sufficiently large portion of > program? The problem is that by creating the line_table with physical locations out-of-order, LTO is 1) creating a lot of maps, even for small column changes. Thus, consuming a= lot of extra memory. 2) increasing location_t values rapidly, thus probably triggering an overfl= ow.=20 The line-maps.c code already dynamically disables column numbers when location_t values get very large (I think this is the reason that there are= no column numbers in the examples you show). If the location_t numbers get even larger, it will start returning UNKNOWN_LOCATION. Now I think that if you s= ee wrong line numbers is most probably because of wrong location info in the front-ends, not because linemaps overflowed. There is also some mismatch between the limits used by linemap_line_start(): if (max_column_hint > LINE_MAP_MAX_COLUMN_NUMBER || highest > 0x60000000) { /* If the column number is ridiculous or we've allocated a huge number of source_locations, give up on column numbers. */ max_column_hint =3D 0; if (highest > 0x70000000) return 0; /* Give up completely and return UKNOWN_LOCATION */ column_bits =3D 0; } and the limits used by linemap_position_for_column: if (to_column >=3D set->max_column_hint) { if (r >=3D 0xC000000 || to_column > LINE_MAP_MAX_COLUMN_NUMBER) { /* Running low on source_locations - disable column numbers. */ return r; } else { struct line_map *map =3D LINEMAPS_LAST_ORDINARY_MAP (set); r =3D linemap_line_start (set, SOURCE_LINE (map, r), to_column + = 50); } } I'm not sure if the gap may lead to some problem, but it seems unlikely. In= the worst case, it should return 0, thus UNKNOWN_LOCATION (I can see some insta= nces of this in your examples). >>From gcc-bugs-return-481502-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 24 19:39:03 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 94035 invoked by alias); 24 Mar 2015 19:39:03 -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 93970 invoked by uid 55); 24 Mar 2015 19:39:00 -0000 From: "jason at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/65498] [5 Regression] ICE in cxx_eval_call_expression when using __func__ inside dependent context Date: Tue, 24 Mar 2015 20:01:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jason at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jason 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/msg02646.txt.bz2 Content-length: 593 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65498 --- Comment #10 from Jason Merrill --- Author: jason Date: Tue Mar 24 19:38:28 2015 New Revision: 221641 URL: https://gcc.gnu.org/viewcvs?rev=221641&root=gcc&view=rev Log: PR c++/65498 * pt.c (get_mostly_instantiated_function_type): Just return the type of the partially instantiated template in DECL_TI_TEMPLATE. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-targ2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template13.C