From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4285 invoked by alias); 26 Mar 2015 00:08:46 -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 4215 invoked by uid 48); 26 Mar 2015 00:08:40 -0000 From: "manu at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/65536] LTO line number information garbled Date: Thu, 26 Mar 2015 02:45: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: NEW 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/msg02891.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D65536 --- Comment #43 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez --- (In reply to Jan Hubicka from comment #40) > Manuel, > the following way you get the lto1 invocation: Ah, ok, it seems to work now. It just takes ages to print the lto1 line and= it get printed way after the lto1 process is running already. > For proper LTO you need a linker with plugin support check: That seems correct. Thanks. > There is a path in linemap_add_line that does not increase locator, but it > is bit bogus. I am playing with patch to improve this. Which path? What for sure happens is that when linemap_start_line starts returning 0, t= hen linemap_postion_for_column will always return the same location until linemap_add is called directly (because of a change of file in the case of LTO). >>From gcc-bugs-return-481748-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Mar 26 00:19:37 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 40231 invoked by alias); 26 Mar 2015 00:19:37 -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 25200 invoked by uid 55); 26 Mar 2015 00:19:29 -0000 From: "hubicka at ucw dot cz" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/65536] LTO line number information garbled Date: Thu, 26 Mar 2015 02:51: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: hubicka at ucw dot cz X-Bugzilla-Status: NEW 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/msg02892.txt.bz2 Content-length: 1189 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536 --- Comment #44 from Jan Hubicka --- > > Ah, ok, it seems to work now. It just takes ages to print the lto1 line and it > get printed way after the lto1 process is running already. Yep, really anoying property that the stderr output is all buffered and output only at once. Something to do with libiberty. > > There is a path in linemap_add_line that does not increase locator, but it > > is bit bogus. I am playing with patch to improve this. > > Which path? > > What for sure happens is that when linemap_start_line starts returning 0, then > linemap_postion_for_column will always return the same location until > linemap_add is called directly (because of a change of file in the case of > LTO). Ah yes, you are right, it returns 0. I think this is bug too. We probably want to return last map or have a dedicated location for out of range? GCC uses: #define DECL_IS_BUILTIN(DECL) (LOCATION_LOCUS (DECL_SOURCE_LOCATION (DECL)) <= BUILTINS_LOCATION) so I think returning 0 will make us to believe that declaration with out of range location is builtin that will definitly lead to wrong code. Honza