From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127533 invoked by alias); 24 Mar 2015 14:10:35 -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 127419 invoked by uid 48); 24 Mar 2015 14:10:31 -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 14:34: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/msg02581.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D65536 --- Comment #8 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez --- (In reply to Richard Biener from comment #7) > (In reply to Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez from comment #5) > > (In reply to Richard Biener from comment #2) > > > The main issue with LTO is that it re-creates a combined linemap but = in (most > > > of the time) quite awkward ordering (simply registering random-ordered > > > file:line:column entries by switching files/lines "appropriately"). > > >=20 > > > I've argued that it would be better to stream those file:line:columns > > > separately so we can "sort" them before handing them over to libcpp f= or > > > linemap re-creation. Do you mean build the line_table first in order, then when reading in the trees/ statements, find the location_t corresponding to each given file:line:column?=20 Unfortunately, there is no fast way to find the maps that correspond to a g= iven file:line:column.=20 You could collect all physical locations (file:line:columns), perhaps having some sorted list of files that points to a sorted list of line:column pairs. Then go through each file in order and build the line_table incrementally, = once done with a file, LC_RENAME for the next file and continue building the line table and so on. Then, we streaming tree, find the location_t for a given file:line:column by doing a (binary?) search in the list of maps. This last step seems slow, not sure how it could be sped up. > I see. An issue is that we don't keep track of whether we entered a file > already (and after re-computing line-maps we lose any "nesting" of includ= es, > that is, we always have enter/leave pairs). But if LC_RENAME works even > when a file was never LC_ENTERed before then we can use it. >=20 > Not sure if it will make a difference though. I think not much because line-map.c already has code to deal with this. Look for: /* So this _should_ mean we are leaving the main file -- effectively ending the compilation unit. But to_file not being NULL means the caller thinks we are leaving to another file. This is an erroneous behaviour but we'll try to recover from it. Let's pretend we are not leaving the main file. */ > > How are the original locations stored on disk? >=20 > As string for file and two ints for line and column. Thus they are > stored "expanded". But they are interleaved with the trees / stmts they > are associated to. I wonder if it would not be easier to store directly the line_table and location_t per object file, then re-encode location_t when reading to be an index into an array of line_tables, plus the actual location_t. It just nee= ds to be careful to undo the re-encoding and use the correct line_table before passing the info to the line-map functions. >>From gcc-bugs-return-481438-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 24 14:12:13 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 2524 invoked by alias); 24 Mar 2015 14:12:13 -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 2233 invoked by uid 48); 24 Mar 2015 14:12:09 -0000 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/32261] Thread race segfault in std::string::append with -O and -s Date: Tue, 24 Mar 2015 14:38:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 3.3.6 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: VERIFIED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 3.4.6 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/msg02582.txt.bz2 Content-length: 191 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32261 --- Comment #13 from Jonathan Wakely --- For the record, I believe this was fixed by https://gcc.gnu.org/r67912