bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: markus.boeck02 at gmail dot com
Subject: [Bug ld/26103] Assertion failure at ldlang.c:7269 when compiling with LTO on MinGW
Date: Thu, 11 Jun 2020 19:20:04 +0000

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

--- Comment #4 from Markus Böck <markus.boeck02 at gmail dot com> ---
Using git bisect I managed to figure out which commit of GCC 9 has started
causing the issue. I am confused as to how or why it would do so however.
The first commit that causes this bug is: "PR libstdc++/86450 use -Wabi=2 and
simplify -Werror use" with revision number
c3be340eb67fff7ef353d37bd02898f295ea0ef1

Regarding the reproducability I have used following configure options for
building GCC 9:
../configure --target=x86_64-w64-mingw32 --disable-bootstrap
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--prefix=/mnt/c/GCC-Build/NewestLinux
--with-sysroot=/mnt/c/GCC-Build/NewestLinux --disable-libstdcxx-pch
--disable-multilib --with-tune=znver1 --with-cross-host
--disable-libstdcxx-verbose --enable-languages=c,c++,fortran,lto,objc,obj-c++
--disable-nls --disable-win32-registry --enable-shared --with-gnu-ld
--program-prefix=x86_64-w64-mingw32- --enable-threads=posix
--enable-__cxa_atexit --enable-libgomp --with-gnu-as --program-suffix=-9
--without-isl

All tests that I performed have been using the same version of MinGW (close to
current trunk) as well as the binutils at the revision specified in the
original post.

Additionally I ran gdb to check which symbol cause the re-inclusion of
libstdc++. The function with the assert 'ldlang_add_file' is called by
'add_archive_element', whose name parameter has following content:
".weak._ZSt4swapISt6localeENSt9enable_ifIXsrSt6__and_IISt6__not_ISt15__is_tuple_likeIT_EESt21is_move_constructibleIS5_ESt18is_move_assignableIS5_EEE5valueEvE4typeERS5_SF_._ZStanSt12_Ios_IostateS_"

Last I tried to print and compare the symbol table of ios.o both before and
after the bad commit. I ran llvm-objdump -t on both versions of libstdc++ and
removed all other object files but ios.o in the output. Only the object file
after the bad commit contains .weak symbols that might trip up the linker. I
have attached both symbols tables of the working compiler and the one
triggering the assert.

Please tell me if there is anything more that I can do for you and thank you
for your patience and time already spent!

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]