[build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)

Paolo Bonzini bonzini@gnu.org
Mon Mar 21 10:27:00 GMT 2011


On 03/21/2011 11:18 AM, Rainer Orth wrote:
> Richard Guenther<rguenther@suse.de>  writes:
>
>> On Fri, 18 Mar 2011, Rainer Orth wrote:
>>
>>> Richard Guenther<richard.guenther@gmail.com>  writes:
>>>
>>>> It seemed to have disabled linker-plugin support for old binutils
>>>> with --with-plugin-ld=/usr/local/bin/gold, explicit -fuse-linker-plugin says
>>>> it is not supported.  The system linker does not have plugin support
>>>> (nor gold).  /usr/local has gold from binutils 2.20.50.xxx.  So it seems that
>>>>
>>>>      # Allow -fuse-linker-plugin to enable plugin support in GNU gold 2.20.
>>>>      elif test "$ld_is_gold" = yes -a "$ld_vers_major" -eq 2 -a
>>>> "$ld_vers_minor" -eq 20; then
>>>>        gcc_cv_lto_plugin=1
>>>>      fi
>>>>
>>>> only allows explicit -fuse-linker-plugin for recent gold but based on checking
>>>> the system linker version (instead of that of --with-plugin-ld).  I'd say
>>>> allow explicit -fuse-linker-plugin always if --with-plugin-ld is specified.
>>>
>>> Agreed.  I'll have a look and refrain from installing on 4.6 until this
>>> is resolved.  I wasn't even aware of --with-plugin-ld, which isn't
>>> documented in install.texi ;-(  This stuff seems insanely complicated to
>>> me, though: which user is supposed to deal with such complications?
>>
>> It's sort of historic ... with plugin support for GNU ld we can probably
>> drop this flag for 4.7 (eventually I'd even like to enforce the use
>> of the plugin all the time or disable LTO, just for the sake of reducing
>> the testing and bugreporting matrix ...).
>>
>> I just noticed the above with the LTO setup of our SPEC testers
>> which are using somewhat old system tools.
>
> Here's the patch I came up with.  It is on top of the previous one, so
> if we want to backport to 4.6 later, both are necessary.
>
> It also fixes a typo in the in_tree_ld case, which can never have worked.
>
> Tested by i386-pc-solaris2.11 bootstraps with either Sun ld or gld 2.21,
> and by configuring with Sun ld --with-plugin-ld=gld-2.21 and obvserving
> HAVE_LTO_PLUGIN being set to 1.
>
> Ok for mainline now and 4.6 after some soak time?
>
> Thanks.
> 	Rainer
>
>
> 2011-03-19  Rainer Orth<ro@CeBiTec.Uni-Bielefeld.DE>
>
> 	* configure.ac (gcc_cv_lto_plugin): Fix typo.
> 	Allow -fuse-linker-plugin for non-default plugin linker.
> 	* configure: Regenerate.
>
> diff -r 916a52719d80 gcc/configure.ac
> --- a/gcc/configure.ac	Sat Mar 19 08:54:19 2011 +0100
> +++ b/gcc/configure.ac	Sun Mar 20 13:37:38 2011 +0100
> @@ -3192,14 +3192,14 @@
>   AC_MSG_CHECKING(linker plugin support)
>   gcc_cv_lto_plugin=0
>   if test -f liblto_plugin.la; then
> -  if test $in_tree_ld = yes -a x"$ORIGINAL_PLUGIN_LD_FOR_TARGET=" = x"$gcc_cv_ld"; then
> +  if test $in_tree_ld = yes -a x"$ORIGINAL_PLUGIN_LD_FOR_TARGET" = x"$gcc_cv_ld"; then
>       if test "$gcc_cv_gld_major_version" -eq 2 -a "$gcc_cv_gld_minor_version" -ge 21 -o "$gcc_cv_gld_major_version" -gt 2; then
>         gcc_cv_lto_plugin=2
>       elif test "$ld_is_gold" = yes -a "$gcc_cv_gld_major_version" -eq 2 -a "$gcc_cv_gld_minor_version" -eq 20; then
>         gcc_cv_lto_plugin=1
>
>       fi
> -  elif echo "$ld_ver" | grep GNU>  /dev/null; then
> +  elif test x"$ORIGINAL_PLUGIN_LD_FOR_TARGET" = x"$gcc_cv_ld"&&  echo "$ld_ver" | grep GNU>  /dev/null; then
>       # Require GNU ld or gold 2.21+ for plugin support by default.
>       if test "$ld_vers_major" -eq 2 -a "$ld_vers_minor" -ge 21; then
>         gcc_cv_lto_plugin=2
> @@ -3207,6 +3207,10 @@
>       elif test "$ld_is_gold" = yes -a "$ld_vers_major" -eq 2 -a "$ld_vers_minor" -eq 20; then
>         gcc_cv_lto_plugin=1
>       fi
> +  elif test x"$ORIGINAL_PLUGIN_LD_FOR_TARGET" != x"$gcc_cv_ld"; then
> +    # Allow -fuse-linker-plugin if plugin linker differs from
> +    # default/specified linker.
> +    gcc_cv_lto_plugin=1
>     fi
>   fi
>   AC_DEFINE_UNQUOTED(HAVE_LTO_PLUGIN, $gcc_cv_lto_plugin,

I haven't followed the thread enough to understand the issue, but the 
patch is trivial enough that I can defer to Richard about it.

Paolo



More information about the Gcc-patches mailing list