This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH,RFC] collect2 LTO for AIX
- From: David Edelsohn <dje dot gcc at gmail dot com>
- To: Martin Liška <mliska at suse dot cz>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 5 Jul 2019 21:03:08 -0400
- Subject: Re: [PATCH,RFC] collect2 LTO for AIX
- References: <CAGWvnymeyvkoqoxnjvQGhTv3UfVgpPW3wpuFW2-gUtt0krSAemail@example.com> <firstname.lastname@example.org> <CAGWvnykYRvA49GKTyDELi20zKWJYzfsyJjwE=9Nd07WJj2aUXw@mail.gmail.com> <email@example.com>
On Thu, Jul 4, 2019 at 11:43 AM Martin Liška <firstname.lastname@example.org> wrote:
> On 7/4/19 5:03 PM, David Edelsohn wrote:
> > On Thu, Jul 4, 2019 at 10:38 AM Martin Liška <email@example.com> wrote:
> >> Hi.
> >> Recently I've introduced a new .gnu.lto_.lto section that
> >> is supposed to provide meta information about a LTO bytecode.
> >> As a further step, I'm planning to teach binutils about
> >> existence of the section and I'll remove in the future
> >> emission of __gnu_lto_slim and __gnu_lto_v1 symbols.
> >> The former one is used by binutils to identify if
> >> an object is a slim LTO object. The later one is currently
> >> used only in gcc/collect2.c and was added by David's patch.
> >> My question is: Can we remove __gnu_lto_v1 right now and
> >> XCOFF will use something similar to ELF (has_lto_section)?
> >> Can you David help me with that please?
> > LTO currently does not work on AIX. I added the __gnu_lto_v1 as a
> > test. You can rip it out and XCOFF will follow a different path when
> > implementing LTO.
> Great. Then I'm sending revert of the patch.
> Ready to be installed?