[Bug lto/106274] Loss of macro tracking information with -flto

rguenth at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Wed Jul 13 06:38:07 GMT 2022


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

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 make
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 optimization
(but this runs into the same issue that late diagnostics then appear
"mangled").


More information about the Gcc-bugs mailing list