From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B5CA43858C78; Fri, 12 May 2023 07:25:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B5CA43858C78 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1683876333; bh=JqxPbYgsgxQ/6ESrLfVW5S6TJJM3EIkvAfbIxjLjGUo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=OV4TmoR+5nZ8H0MW079F8zJb9Pi1m2rqNLcacQyIJwC26Cl5i6gmxIBQYdq7vioEn YI2Cmcktv1g+yQxLMqUmYYfDQZ//gClnhtqwb21aKwH0DBq0VMVHtx6/Mt9HZKgen+ WyZ4NWtJbuq8dP4YHaQUCa5qEcP50G4r9ijapzEw= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/109805] LTO affecting -fdebug-prefix-map Date: Fri, 12 May 2023 07:25:33 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: debug X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: lto X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: 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: everconfirmed bug_status cf_reconfirmed_on 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109805 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed| |2023-05-12 --- Comment #7 from Richard Biener --- OK, so the .debug_line entries appear because of main:=20=20=20 .LFB0:=20=20 .file 1 "t.c" .loc 1 1 11 I think I've seen a duplicate bugreport about this where it was suggested we should apply the remapping when we stream locations. But that also has effects on diagnostics we emit during LTRANS. The pragmatic approach with lto-wrapper would still work, but this shows why a "proper" solution is even more difficult.=