This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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?

Thanks.

-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]