On Mon, Jul 2, 2012 at 1:06 PM, Alexandre Oliva <aol...@redhat.com> wrote: > On Jun 29, 2012, Mike Stump <mikest...@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