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: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)


Richard Guenther <rguenther@suse.de> writes:

>> Only with -save-temps, otherwise it's some random file in /var/tmp.  But
>> even so the file is removed immediately.
>
> The following seems to work for me
>
> Index: gcc/testsuite/lib/target-supports.exp
> ===================================================================
> --- gcc/testsuite/lib/target-supports.exp       (revision 170868)
> +++ gcc/testsuite/lib/target-supports.exp       (working copy)
> @@ -1011,9 +1011,20 @@ proc check_effective_target_static_libgf
>  }
>  
>  proc check_linker_plugin_available { } {
> -  return [check_no_compiler_messages_nocache linker_plugin executable {
> +  set result [eval check_compile { linker_plugin object {
>       int main() { return 0; }
> -  } "-flto -fuse-linker-plugin"]
> +  } "-flto" } ]
> +  set lines [lindex $result 0]
> +  set output [lindex $result 1]
> +  set result [gcc_target_compile $output linker_plugin[pid] executable { 
> additional_flags=-flto additional_flags=-flto-partition=none 
> additional_flags=-save-temps } ]
> +  remote_file build delete $output
> +  remote_file build delete linker_plugin[pid]
> +  remote_file build delete linker_plugin[pid].s
> +  if [file exists linker_plugin[pid].res] {
> +    remote_file build delete linker_plugin[pid].res
> +    return 1
> +  }
> +  return 0
>  }

Still doesn't work for me if compiling and linking manually with GNU ld
2.21 on Solaris 11/x86: no .res file is being created, although
liblto_plugin.so is used.

> Eventually scanning -v output for '-plugin' is better.

This can only work if we make sure that -plugin is only passed to
linkers that properly handle it.

>> And even if we decide to fix PR lto/46944 like this, we're still left
>> with the problem of users invoking gcc with -fuse-linker-plugin and
>> getting either strange errors or no effect instead of a clear
>> diagnostic.
>
> Sure.  But just disabling linker-plugin support for almost everyone
> doesn't sound like a good solution either.

Why do you say so?  The tri-state solution I've outlined only disables it
completely for non-GNU linkers.  The plugin is used automatically for
gld/gold 2.21+ and for gold 2.20* if -fuse-linker-plugin is given.

I don't see the `almost everyone' here, on the contrary: the situation
is identical to what we have now, with the exception that we don't try
to pass -plugin to linkers we don't know they can somehow (even with
restrictions) handle it.  That's what PR lto/46944 is primarily about.

	Rainer

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


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