bug-binutils
[Top][All Lists]
Advanced

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

[Bug ld/12248] Linker plugin failed to preserve linking order


From: hjl.tools at gmail dot com
Subject: [Bug ld/12248] Linker plugin failed to preserve linking order
Date: Mon, 24 Jan 2011 01:24:13 +0000

http://sourceware.org/bugzilla/show_bug.cgi?id=12248

--- Comment #17 from H.J. Lu <hjl.tools at gmail dot com> 2011-01-24 01:24:01 
UTC ---
(In reply to comment #16)
> It looks counterintuitive to me.
> 
> > LTO in x.o doesn't reference __udivdi3
> 
> But a reference to __udivdi3 from bar is generated on LTO step:
> /tmp/cczLpgd5.ltrans0.ltrans.o: reference to __udivdi3

This is internal implementation of LTO, which calls __udivdi3
in libgcc. LTO may also choose to inline it.

> BTW, behavior of `gcc -B./ -o foo -O2 -fwhole-program -flto=jobserver
> -fuse-linker-plugin y.o x.o libdiv.a' depends on the presence / absence of IR
> sections in libdiv.a (links with libgcc / libdiv.a). I think it's a bug.

This is intentional. Since libdiv.a with IR isn't used by LTO in stage 1
linking, it can't be used in stage 2 either. Otherwise, stage 2 linking
may lead to undefined symbols if libdiv uses some external variables,
which are defined in some IR inputs and optimized out by LTO since LTO
didn't see their references in libdiv.a. I checked some LTO testcases
into hjl/lto-mixed branch to verify it.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- 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]