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

Alexandre Oliva aoliva@redhat.com
Mon Jul 2 11:06:00 GMT 2012


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.

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.

-- 
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



More information about the Gcc-patches mailing list