Re: [testsuite] don't use lto plugin if it doesn't work

[Richard Guenther <richard dot guenther at gmail dot com>]

On Mon, Jul 2, 2012 at 1:06 PM, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Jun 29, 2012, Mike Stump <mikestump@comcast.net> wrote:
>
>> First, let get to the heart of the matter.  That is the behavior of
>> compiler.
>
> That's a distraction in the context of a patch to improve a feature
> that's already present in the testsuite machinery, isn't it?  I have no
> objection to discussing this other topic you want to bring forth, but
> for reasons already stated and restated I don't think it precludes the
> proposed patch and the improvements to testsuite result reporting it
> brings about.
>
>>Do you think it works perfectly and needs no changing in this area
>
> I think the compiler is working just fine.  It is told at build time
> whether or not to expect a linker with plugin support at run time, and
> behaves accordingly.
>
> Configure detects that based on linker version, which is in line with
> various other binutils feature tests we have in place, so I don't see
> that the test *needs* changing.  If it were to change in such a way
> that, in a “native cross” build scenario, it failed to detect plugin
> support that is actually available on the equivalent linker one would
> find on the configured host=target run time platform, I'd be inclined to
> regard that as a regression and a bug.
>
>> My take was, the compiler should not try and use the plugin that won't work, and that this should be a static config bit built up from the usual config time methods for the host system.  Do you agree, if not why, and what is your take?
>
> I agree with that.  Indeed, it seems like a restatement of what I just
> wrote above, unless one thinks configure should assume the user lied in
> the given triplets.  Because, really, we *are* lying to configure when
> we say we're building a i686-linux-gnu native natively when the build
> system is actually a x86_64-linux-gnu with some wrapper scripts that
> approximate i686-linux-gnu.  If we tell configure we're building a
> compiler for an i686-linux-gnu system, configure should listen to us,
> rather than second-guess us.  And if we fail to provide it with an
> environment that is sufficiently close to what we asked for, it's
> entirely our own fault, rather than configure's fault for not realizing
> we were cheating and compensating for our lies.
>
> Now, of course, none of this goes against an ability to explicitly
> specify whether or not to build a plugin, or to expect it to work with
> the linker-for-target on host.  But I don't think we should change the
> current default detection for the sake of the i686-native-on-x86_64
> scenario, for it really is the best we can do in such a
> native-but-not-quite scenario, for we can't possibly test properties of
> the actual native linker if what's available at build time is some other
> linker.
>
> What we *can* and *should* do, IMHO, is to improve the test machinery,
> so that if we happen to test a toolchain built for i686 on a non-i686
> system whose linker fails to load the i686 plugin, we don't waste time
> testing stuff the testsuite itself has already detected as
> nonfunctional, and we avoid the thousands of failures that would ensue.

If you consider what happens if we break the lto-plugin so that it fails
loading or crashes the linker, then it's clear that we _do_ want to see
this effect in the testsuite as FAIL.  Merely making tests UNSUPPORTED
in this case is not what we want ...

> Another thing we may want to do documentat how to test GCC in such
> fake-native settings, so that people can refer to it and save duplicate
> effort and avoid inconsistent results.

... which means that maybe we should not encourage such settings at all.

Richard.

> --
> Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
> You must be the change you wish to see in the world. -- Gandhi
> Be Free! -- http://FSFLA.org/   FSF Latin America board member
> Free Software Evangelist      Red Hat Brazil Compiler Engineer