On Mon, Nov 10, 2014 at 5:44 AM, Richard Biener <richard.guent...@gmail.com> wrote: > On Mon, Nov 10, 2014 at 2:43 PM, Jakub Jelinek <ja...@redhat.com> wrote: >> On Mon, Nov 10, 2014 at 05:32:32AM -0800, H.J. Lu wrote: >>> On Mon, Nov 10, 2014 at 4:05 AM, Jakub Jelinek <ja...@redhat.com> wrote: >>> > On Mon, Nov 10, 2014 at 12:50:44PM +0100, Richard Biener wrote: >>> >> On Sun, Nov 9, 2014 at 5:46 PM, H.J. Lu <hongjiu...@intel.com> wrote: >>> >> > Hi, >>> >> > >>> >> > r216964 disables bootstrap for libcc1 which exposed 2 things: >>> >> > >>> >> > 1. libcc1 isn't compiled with LTO even when GCC is configured with >>> >> > "--with-build-config=bootstrap-lto". It may be intentional since >>> >> > libcc1 is disabled for bootstrap. >>> >> > 2. -fPIC isn't used to created libcc1.so, which is OK if libcc1 is >>> >> > compiled with LTO which remembers PIC option. >>> >> >>> >> Why is this any special to LTO? If it is then it looks like a LTO >>> >> (driver) issue to me? Why are we linking the pic libibterty into >>> >> a non-pic libcc1? >>> > >>> > I admit I haven't tried LTO bootstrap, but from normal bootstrap logs, >>> > libcc1 is built normally using libtool using -fPIC only, and linked into >>> > libcc1.so.0.0.0 and libcc1plugin.so.0.0.0, and of course against the >>> > pic/libiberty.a, because we need PIC code in the shared libraries. >>> > So, I don't understand the change at all. >>> > >>> > Jakub >>> >>> This is the command line to build libcc1.la: >> >> Sure, but there was -fPIC used to compile all the *.o files that are being >> linked into libcc1.so, so LTO should know that. > > And it does. If not please file a bug with a smaller testcase than libcc1 > and libiberty. >
There is nothing wrong with linker. It is a slm-lto bug in libtool. I uploaded a testcase at https://gcc.gnu.org/bugzilla/attachment.cgi?id=33931 -- H.J.
