On Fri, 11 Mar 2011, Rainer Orth wrote:
> Richard Guenther <rguent...@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.
"Work" as in, it detects if -fuse-linker-plugin is enabled by default.
Which it isn't for you?
> > 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.
Sure, but your version check patch part would ensure that, if not
overridden by -fuse-linker-plugin.
> >> 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.
Can you update your patch with the tri-state solution?
Thanks,
Richard.
