[build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)
Richard Guenther
rguenther@suse.de
Fri Mar 11 12:30:00 GMT 2011
On Thu, 10 Mar 2011, Rainer Orth wrote:
> Richard Guenther <rguenther@suse.de> writes:
>
> >> > 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.
> >
> > It might be as simple as
> >
> > int res;
> > int main() { int x; asm ("mov res, %0" : x(g)); return x; }
> >
> > which should fail to link with the plugin only (but yes, requies
> > target dependent assembly ...).
>
> ... which I'd consider far too complicated/hard to maintain to consider.
>
> > Or, use -save-temps and check for the existence of the resolution
> > file for int main() {}. It should be named t.res for gcc -o t t.c -flto.
>
> 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
}
# Return 1 if the target supports executing 750CL paired-single
instructions, 0
it leaves an argument file in /tmp but otherwise nothing.
Eventually scanning -v output for '-plugin' is better.
> 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.
I'm ok with fixing 46944 somehow at this point, as well as making
-fuse-linker-plugin the default only for known good linker versions.
Richard.
More information about the Gcc-patches
mailing list