public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
To: Richard Guenther <rguenther@suse.de>
Cc: gcc-patches@gcc.gnu.org, Paolo Bonzini <bonzini@gnu.org>
Subject: Re: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)
Date: Thu, 10 Mar 2011 16:51:00 -0000	[thread overview]
Message-ID: <yddaah2x6l0.fsf@manam.CeBiTec.Uni-Bielefeld.DE> (raw)
In-Reply-To: <alpine.LNX.2.00.1103101314250.25982@zhemvz.fhfr.qr> (Richard	Guenther's message of "Thu, 10 Mar 2011 13:26:22 +0100 (CET)")

Richard Guenther <rguenther@suse.de> writes:

> If I read this patch correctly then
>
>  1) it doesn't change the condition under which lto-plugin/ is built
>     (good)

Right.

>  2) it makes -fuse-linker-plugin the default for and only for
>     known good linkers (GNU binutils >= 2.21) (good)

Indeed.

>  3) it makes it impossible to use -fuse-linker-plugin explicitly
>     for other linkers or linkers that were not installed during
>     configuring gcc (bad - esp. the latter)
>
> can you please try avoiding 3) at this stage?  Or is the whole
> point of this patch 3) to be able to fix PR46944?

That was my goal: the Solaris linker accepts -p <auditlib>, which causes
confusion when it is called with -plugin.

> Ideally we'd reject broken linkers at runtime, but that would
> require some major collect2 massaging (eventually falling back
> to collect2 or simply reporting an error).

What about making LTO_PLUGIN 3-valued?

2	linker used has full -plugin support, i.e. gld/gold >= 2.21
1       linker has some -plugin support, i.e. gold >= 2.20 < 2.21
0       linker has no known plugin support, i.e. everything else, in
        particular vendor linkers

We'd default to -fuse-linker-plugin for 2, accept it if given explicitly
for 1, and reject it for 0.

This would be similar to the first version of my patch, with the
difference that we don't try to determine the level of -plugin support
from trying to run the configured linker with -plugin and check if it
works, but instead hardcode that knowledge.

> That said, I'm not 100% happy with 3) at this point (though
> 2) is very desirable).
>
> Can we to fix 46944 change the dejagnu require-linker-plugin
> to check if a linker plugin is used by default and not add
> -fuse-linker-plugin?

That might be involved since it requires parsing gcc -Wl,-debug output.
I suppose the solution outlined above is simpler and thus more robust.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

  reply	other threads:[~2011-03-10 16:51 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-07 12:11 Rainer Orth
2011-02-14 19:44 ` Ralf Wildenhues
2011-03-10 11:26 ` Rainer Orth
2011-03-10 11:51   ` Paolo Bonzini
2011-03-10 12:26   ` Richard Guenther
2011-03-10 16:51     ` Rainer Orth [this message]
2011-03-10 17:06       ` Richard Guenther
2011-03-10 18:28         ` Rainer Orth
2011-03-11 12:30           ` Richard Guenther
2011-03-11 14:37             ` Rainer Orth
2011-03-11 15:10               ` Richard Guenther
2011-03-11 15:18                 ` Rainer Orth
2011-03-11 15:32                   ` Richard Guenther
2011-03-11 15:35                     ` Rainer Orth
2011-03-14 19:07                     ` Rainer Orth
2011-03-15  9:42                       ` Richard Guenther
2011-03-16  9:23                         ` Rainer Orth
2011-03-16  9:27                           ` Paolo Bonzini
2011-03-16  9:43                             ` Rainer Orth
2011-03-18  9:27                         ` Rainer Orth
2011-03-18 10:09                           ` Richard Guenther
2011-03-18 10:16                             ` Rainer Orth
2011-03-18 10:19                               ` Richard Guenther
2011-03-18 10:23                                 ` Rainer Orth
2011-03-18 10:34                                   ` Richard Guenther
2011-03-21 10:18                                 ` Rainer Orth
2011-03-21 10:27                                   ` Paolo Bonzini
2011-03-21 10:27                                   ` Richard Guenther
2011-03-26  3:26 Michael Matz
2011-03-26 11:15 ` Richard Guenther
2011-03-28 10:20   ` Rainer Orth
2011-03-28 10:50     ` Richard Guenther
2011-04-04 16:16   ` Rainer Orth
2011-04-11 13:26     ` Rainer Orth
2011-04-18 18:34     ` Ralf Wildenhues
2011-04-19 17:53       ` Rainer Orth
2011-04-26 16:01         ` Rainer Orth
2011-04-26 22:27           ` Ralf Wildenhues
2011-04-27 14:36             ` Rainer Orth
2011-04-19 12:28     ` Paolo Bonzini
2011-04-19 17:57       ` Rainer Orth
2011-05-30 10:27     ` Rainer Orth
2011-05-30 10:45       ` Richard Guenther

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=yddaah2x6l0.fsf@manam.CeBiTec.Uni-Bielefeld.DE \
    --to=ro@cebitec.uni-bielefeld.de \
    --cc=bonzini@gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=rguenther@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).