On Tue, Jun 30, 2026 at 5:03 AM Lewis Hyatt <[email protected]> wrote:
>
> On Wed, Apr 22, 2026 at 04:29:41PM +0200, Richard Biener wrote:
> > On Thu, Jan 1, 2026 at 6:03 PM Lewis Hyatt <[email protected]> wrote:
> > >
> > > After the previous changes in this series, the LTO front end always has an
> > > appropriate linemap structure for interpreting diagnostic pragmas, so it
> > > is
> > > straightforward to implement them, as is done here.
> > >
> > > The pragmas are streamed out in each linemap section; since all locations
> > > from a given linemap section will be contiguous in the reconstructed
> > > linemap, they are automatically ordered properly for the existing
> > > diagnostic
> > > pragma infrastructure to work as-is.
> > >
> > > One wrinkle is that a single function may have been streamed out in
> > > multiple
> > > sections. (For example, an inline function will be streamed out in all
> > > partitions that need it.) In this case, when merging them, LTO keeps only
> > > one of the sections, as directed by the linker resolution, so the
> > > diagnostic
> > > pragmas that will be in force (in case they were not the same for the
> > > different translation units) will be whichever were applicable to the
> > > section LTO decided to keep.
> >
> > LGTM if the rest of the series is approved.
> >
> > Thanks,
> > Richard.
> >
>
> Hi Richard-
>
> Firstly, thank you again for your time in reviewing these patches. I thought
> everything was finally across the finish line, but as I was reviewing the
> patches one more time before pushing them, I realized there is one small
> problem with the new approach. Could I please ask you to look at one more
> patch which addresses that? I attached it here as an incremental change to
> the rest of the series, but I would propose to squash it into the other
> patches before pushing.
>
> What I missed was that the LTO front end has a mode of operation for
> incremental linking. I had tested that my new approach works fine with
> "ld -r" (provided that -frandom-seed is not used to remove uniqueness from
> the section names), but the LTO front end version of that (which you get
> when using, say, "gcc -r -flto") does more than just copy the sections; it
> actually reads all the decls and then re-outputs a new object file with a
> new identifier, which contains a new decls section plus copies of the
> function and constructor sections. This means the linemap sections also need
> to get copied into the output file, and also, it means that an input file to
> the LTO front end could possibly contain more than one linemap, which was
> not something I had considered. (I had anticipated that inputs contained
> just one linemap, except that in LTRANS mode, there would also be one file
> containing all necessary linemaps copied during WPA).
So I think there's two things now, the older -flto-linker-output=rel and
the newer -flto-incremental.
That said, I'm not sure about the default behavior of -flto -r and would
suggest to add an explicit -flto-linker-output=rel here to be unambiguous.
Did you try that with -ffat-lto-objects as well?
> It wasn't too bad to adapt things to work fine in this case too, so the
> attached patch is not too huge of a change as far as LTO. A lot of the patch
> consists of changes to testsuite/lib/lto.exp to enable testing the
> incremental link mode. There was not any test coverage previously for this
> sort of operation:
>
> g++ -flto -c t{1,2,3}.cc
> g++ -flto -r -o t12.o t{1,2}.o
> g++ -flto -o t t12.o t3.o
>
> (i.e., partial linking of some files and then a final link of all of them
> together), which is why I didn't see this problem initially. The patch adds
> a new directive { dg-lto-do incr-link }, which tests a sequence like the
> above, similar to how { dg-lto-do ar-link } already works. gccint was
> missing documentation of ar-link, so I added something for that as well as
> for incr-link.
>
> I tested everything again on x86-64, aarch64 (cfarm425), amd64 (cfarm420),
> sparc 32-bit (cfarm216), and ppc64be (cfarm121), including bootstrap with
> bootstrap-lto, and it looks good. Please let me know if it looks OK, in
> which case, I am ready to commit the series now. Thanks!
That said, the patch looks reasonable, but I wouldn't call myself an expert
in the area of incremental LTO, of neither mode.
So please give Honza and/or Michal the change to chime in.
Thanks,
Richard.
>
> -Lewis
