On Fri, Nov 14, 2014 at 2:19 AM, Richard Biener <richard.guent...@gmail.com> wrote: > On Fri, Nov 14, 2014 at 12:15 AM, H.J. Lu <hjl.to...@gmail.com> wrote: >> On Tue, Nov 11, 2014 at 8:02 AM, H.J. Lu <hjl.to...@gmail.com> wrote: >>> On Mon, Nov 10, 2014 at 11:42 AM, H.J. Lu <hjl.to...@gmail.com> wrote: >>>> 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 >>>> >>> >>> My patch is a backport of libtool LTO support: >>> >>> commit b81fd4ef009c24a86a7e64727ea09efb410ea149 >>> Author: Ralf Wildenhues <ralf.wildenh...@gmx.de> >>> Date: Sun Aug 29 17:31:29 2010 +0200 >>> >>> Support GCC LTO on GNU/Linux. >>> >>> * libltdl/config/ltmain.m4sh (func_mode_link): Allow through >>> flags matching -O*, -flto*, -fwhopr, -fuse-linker-plugin. >>> * libltdl/m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS): Drop symbols >>> starting with __gnu_lto. >>> (_LT_LINKER_SHLIBS) [linux] <archive_cmds, archive_expsyms_cmds>: >>> Add $pic_flag for GCC. >>> (_LT_LANG_CXX_CONFIG) [linux] <archive_cmds, archive_expsyms_cmds>: >>> Likewise. >>> (_LT_SYS_HIDDEN_LIBDEPS): Ignore files matching *.lto.o. >>> * NEWS: Update. >>> >>> Signed-off-by: Ralf Wildenhues <ralf.wildenh...@gmx.de> >>> >>> OK to install? >>> >> >> Ping. >> >> Stage 1 will be closed tomorrow. I'd like to restore LTO bootstrap. > > Bugfixing is still possible after that date. I suppose you don't call > LTO bootstrap a new feature ;) >
New LTO bugs have been introduced since LTO bootstrap was broken a few weeks ago. I'd like to check in this one so that we have a chance to prevent further damage. Any objects to backport this from libtool upstream? -- H.J.
