From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 4A3963858418; Wed, 13 Jul 2022 06:38:07 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4A3963858418
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/106274] Loss of macro tracking information with -flto
Date: Wed, 13 Jul 2022 06:38:07 +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: 12.1.0
X-Bugzilla-Keywords: diagnostic, 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 cf_reconfirmed_on version keywords
 bug_status
Message-ID: <bug-106274-4-IAH3Zccaff@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-106274-4@http.gcc.gnu.org/bugzilla/>
References: <bug-106274-4@http.gcc.gnu.org/bugzilla/>
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-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jul 2022 06:38:07 -0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106274

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-07-13
            Version|unknown                     |12.1.0
           Keywords|                            |diagnostic, lto
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think the point is that in free-lang-data we are bulldozering over data
structures that the frontend might not be happy about (in the attempt to ma=
ke
the streamed IL small), so we try to reset all callbacks into frontend code
that might crash.

I'm not sure to what extent this is still required with respect to the
diagnostic context though - you'd have to try.

There's also the old long-standing TODO to perform this "frontend scrapping"
also when not using -flto just to save on memory for the followup optimizat=
ion
(but this runs into the same issue that late diagnostics then appear
"mangled").=