Re: Help in tracking down unusual apparent 5.2.0 LTO issue

[Markus Trippelsdorf <markus at trippelsdorf dot de>]

On 2016.03.17 at 23:15 -0500, Matt Godbolt wrote:
> I've just spent a good few hours trying to reproduce, with no success.
> I've also tried tracing the symbol with "-y" in both my (attempted)
> repro case and the error case.
> 
> In the repro case, the ~function() is not even generated with LTO: it
> seems the trivial destructor is inlined in all cases. The non-LTO copy
> is generated and is the one that's linked with. (I'm using -O3 for LTO
> objects and -O0 for non-LTO like my error case has).
> 
> In the error case, the symbol is defined in two places:
> out/haswell/main/SystemExit.o: definition of _ZNSt8functionIFvvEED1Ev
> lib/libseasocks.a(Server.cpp.o): definition of _ZNSt8functionIFvvEED1Ev
> 
> std::function<void()> is used all over the code; so I suspect the
> "SystemExit.o" file is just the place the LTO decided to generate it.
> That said; I could only find references to the symbol in any of the
> -save-temps *ltrans.*.s files. There's a "    .set
> _ZNSt8functionIFvvEED1Ev,_ZNSt8functionIFvvEED2Ev" in that file;
> c++filt demangles the latter as the same as the former; and the latter
> *is* defined. I wonder if this apparent "rename" (or whatever .set is)
> is confusing the linker further on. That said; the "1" and "2" version
> are both seemingly present in the library (libseasocks.a) too (as a
> weak reference, according to nm).
> 
> I really wish I could reproduce this! I'm posting this follow-up just
> in case anything I've done or seen above jogs someone's memory or if
> anyone has any further thoughts on what the root cause may be.

I think at this point you should just open a gold bug and post your
analysis there, because the gold maintainer probably doesn't read the
gcc-help ML.

-- 
Markus