From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39753 invoked by alias); 25 Mar 2015 09:54:00 -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 39686 invoked by uid 48); 25 Mar 2015 09:53:56 -0000 From: "rguenth 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 10:12: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: 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: --- 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/msg02714.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536 --- Comment #32 from Richard Biener --- (In reply to Jan Hubicka from comment #16) > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536 > > > > --- Comment #2 from Richard Biener --- > > 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"). > > > > 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 for > > linemap re-creation. > > Yep, we discussed this few times. One issue is when we sort them. > We can keep track of location as they are streamed out (and directly assign > them new IDs in the awkward ordering as they come) and then produce the > separate linemap section that would be read at once by WPA, sorted and > fed into linemaps. > > Sorting at compile time is bit tricky as we probably do not want to patch > existing pickled tree stream with the new locator IDs in the sorted sequence > and we do not really know what locations we will need ahead of time. Well, the idea was to stream another index representing the sorted order so we can sort and merge at WPA in O(n) and re-map the index on stream-in time. I don't think we want to sort at WPA time. > Other easier to implement idea for GCC 5 may be to simply collect locaiton > info and pointers to trees per SCC component andonly if it survived merging > feed it into linemap and in memory patch the new trees. This still should > save quite some memory given that most of trees read are discarded by merging > and may be quite easy to implement. > > Martin, the ICE by my patch is caused by libcpp getting out of memory? Btw, we don't have to fix this for GCC 5. We can of course backport a good solution later.