[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