[Bug lto/84213] [8 Regression] 521.wrf_r from SPEC 2017 fails to build (link) with LTO

[derodat at adacore dot com]

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

--- Comment #10 from Pierre-Marie de Rodat <derodat at adacore dot com> ---
(In reply to Richard Biener from comment #8)
> Yeah, setting DECL_PRESERVE_P would make it possible to add the
> location late since we'd not remove the decl.  Currently it's simply
> gone and the early dwarf2out_"late"_global_decl is the last thing
> we see from it...
Ok, understood.

> Currently struggling in getting a debuggable gnat1 built .. it looks
> like ./configure --enable-languages=c++,ada --disable-bootstrap
> no longer works with a host compiler that doesn't understand some
> C++ specs that appear to be used (GCC 4.8).
I’m using GCC 7.2.1. It’s odd that you get this issue only with gnat1, though…

(In reply to Richard Biener from comment #9)
> Another possibility would be to add the info symbolically by refering to the
> early DIE of the other entity.  Not sure if that works for the Ada cases? 
> We have
> DW_OP_GNU_variable_value but in this case we want the DIEs address.
In the original ADa use case, there is no other entity: the variable for which
we want to emit a location is around only for its name, so instead of
allocating a memory slot for it, we produce a “dummy” location (DW_OP_const1s:
-1). So I don’t know: would what you have in mind work? (just keeping producing
a location is enough for Ada, I think)

> Btw, if you compile any of your testcases for the issue with -g -flto
> can you verify if the generated object files contain relocations in the
> early LTO debug sections?  Those should not refer to real symbols...
> else the problem will manifest with Ada as well.
I’m confused: is this query for myself or for one Martin? ;-)

> So I think we do have to revert the revision in question (or put in the
> above hack).
Either way, in the end we need a solution that fixes the SPEC build error and
that does not make Ada debugging regress. :-)

I’m still not familiar with LTO and how early/late passes are supposed to work,
so I lack judgment about what is a hack and what isn’t. Do you think we can
find a clean way to delay location production from the “early late” pass to the
“truly late” one?