https://sourceware.org/bugzilla/show_bug.cgi?id=23935
--- Comment #7 from Vladislav Ivanishin <vlad at ispras dot ru> --- (In reply to H.J. Lu from comment #6) > The behaviors of with and without -ffat-lto-objects should be the same. > Either both work or both don't. Why? I think the behavior of 'with -ffat-lto-objects' here for libfoo.o should match that of 'without -flto at all'. (Which it doesn't.) The test case in the original post is a minified illustration of a bigger test case. And -ffat-lto-objects is there because it allows to reuse the same static archive for dependency resolution on the first pass of the linker (IR in the archive members benefits LTO compilation), and for the rescanning pass, where no_more_claiming is set and the fat archive is acting in the capacity of a regular non-LTO archive. If for this minified test case we compile libfoo instead with just gcc -c -fno-builtin libfoo.c -o libfoo.o , then the rescanning works as expected. Adding IR to libfoo should not change anything, because the linkers currently are not supposed to rescan LTO objects iteratively until reaching a fixed point---rather, they do exactly 2 passes, disregarding IR during the second. My understanding is that fat objects are a possibility (they provide a fallback i.e. the linker should find the appropriate resolution, if it's there), not an imperative to treat them as IR objects. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils