https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536 --- Comment #15 from Manuel López-Ibáñez --- (In reply to Jakub Jelinek from comment #14) > By streaming the line_table directly you'd stream lots of location_t that > are not actually used for anything that is streamed into the LTO. > I don't understand why the tables would be huge, the string would of course > use normal LTO section string sharing, and if we stream right now every > location_t as the triplet, it would mean in case a single location_t is > never used by more than one tree we'd stream an integer extra to what we > stream now (just the triplets would be streamed in a different place), but > in the more common case where one location_t is used by many trees, we'd > stream less than what we stream now, due to the additional indirection. The line_table does not store every possible location_t, only the ones that start new maps, it should not even store one location_t per line! But it is true that a whole file:line:column table for all locations stored in the object file might be smaller than the line_table for the whole TU. It depends a lot how much of the input file ends up in the object file. But I think it should be easy to estimate the size of the line_table (see dump_line_table_statistics). I have no idea how large a file:line:column table would be for a typical object file. If on-disk size is a concern, one can also replace virtual (macro) locations with spelling/expansion point locations and not stream out any macro maps. Moreover, when streaming out, because of how the line_table is encoded as a contiguous array, one can mark the maps that are not used by LTO and simply not stream them out, which may reduce the size of the line_table significantly (and speed up any linemap merging/lookup later). This cannot be much slower than what you are doing already, since expanding "file:line:column" requires finding the map that holds this info. Of course, if you are really unlucky, each location_t used by LTO may belong to a different map, thus you cannot remove anything and then it would have been more efficient to use a file:line:column table. In this worst case, the overhead would be approximately sizeof(struct line_map) * number of rows in the file:line:column table. Even in this worst case, my intuition says that one could re-optimize the line_table to make it more efficient (since one location_t per map is the most inefficient case possible) before streaming out without actually changing the location_t values, but I would need to think a bit more whether this re-optimization is actually possible. Perhaps Dodji can figure out a problem with it. >From gcc-bugs-return-481465-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 24 16:22:23 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 73073 invoked by alias); 24 Mar 2015 16:22:23 -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 72774 invoked by uid 48); 24 Mar 2015 16:22:19 -0000 From: "spam.brian.taylor at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/65542] New: SPREAD intrinsic incorrectly accepted in initialization expressions with -stdù5 Date: Tue, 24 Mar 2015 16:47:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 4.9.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: spam.brian.taylor at gmail dot com 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter Message-ID: 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/msg02609.txt.bz2 Content-length: 883 https://gcc.gnu.org/bugzilla/show_bug.cgi?ide542 Bug ID: 65542 Summary: SPREAD intrinsic incorrectly accepted in initialization expressions with -stdù5 Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: spam.brian.taylor at gmail dot com Prior to the Fortran 2003 standard, only a subset of transformational intrinsic functions were allowed in initialization expressions (specifically: REPEAT, RESHAPE, SELECTED_INT_KIND, SELECTED_REAL_KIND, TRANSFER, and TRIM). See Fortran 95 ISO draft standard, section 7.1.6.1, lines 9-11, page 94. The following code should not compile with -stdù5: module bug integer :: ibug(42) = spread(42, 1, 42) end module