[Bug ld/26103] Assertion failure at ldlang.c:7269 when compiling with LTO on MinGW

[amodra at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26103

--- Comment #5 from Alan Modra <amodra at gmail dot com> ---
I still haven't managed to reproduce the problem, but your symbol dumps give a
clue as to what is going on.

[479](sec  0)(fl 0x00)(ty  20)(scl  69) (nx 1) 0x00000000
_ZSt7forwardIDnEOT_RNSt16remove_referenceIS1_E4typeE
AUX indx 462 srch 1

The above symbol is storage class 105 (llvm-objdump in hex??) or C_NT_WEAK. 
The aux entry points at an alias;

[462](sec 106)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x00000000
.weak._ZSt7forwardIDnEOT_RNSt16remove_referenceIS1_E4typeE._ZStanSt12_Ios_IostateS_

This has ".weak." prepended and some other global symbol name appended, the
idea being to make the alias unique to the object file.  Which isn't very
robust, and may result in multiple symbol definition errors.  But that's not
what you are seeing.

Can you repeat your gdb debug session, going up from add_archive_element to
coff_link_check_archive_element to see the symbol.  Then put a watchpoint on
h->type, running the link again to see changes in h->type.  The one I'm
interested in is a possible change from bfd_link_hash_defined back to
bfd_link_hash undefined, and where that occurs in the source.  You might need
to rebuild binutils at a lower optimisation level than -O2 in order to be able
to do this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.