On Thu, 10 Mar 2011, Rainer Orth wrote: > Richard Guenther <rguent...@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.