From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 61131 invoked by alias); 24 Mar 2015 16:20:01 -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 61010 invoked by uid 48); 24 Mar 2015 16:19:53 -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 16:44: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/msg02607.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D65536 --- Comment #15 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez --- (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 cour= se > 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 ta= ble would be for a typical object file. If on-disk size is a concern, one can a= lso replace virtual (macro) locations with spelling/expansion point locations a= nd 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 fin= ding the map that holds this info.=20 Of course, if you are really unlucky, each location_t used by LTO may belon= g 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 m= ost inefficient case possible) before streaming out without actually changing t= he 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=f95 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?id=65542 Bug ID: 65542 Summary: SPREAD intrinsic incorrectly accepted in initialization expressions with -std=f95 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=f95: module bug integer :: ibug(42) = spread(42, 1, 42) end module