Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Tue, Nov 11, 2014 at 8:02 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Nov 10, 2014 at 11:42 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Mon, Nov 10, 2014 at 5:44 AM, Richard Biener
>> <richard.guenther@gmail.com> wrote:
>>> On Mon, Nov 10, 2014 at 2:43 PM, Jakub Jelinek <jakub@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 <jakub@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.lu@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.Wildenhues@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.Wildenhues@gmx.de>
>
> OK to install?
>

Ping.

Stage 1 will be closed tomorrow.  I'd like to restore LTO bootstrap.


-- 
H.J.