This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Jul 2, 2012, at 4:06 AM, Alexandre Oliva wrote:
> On Jun 29, 2012, Mike Stump <> 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?

Without having a compiler to test, there is little reason to have a testsuite.  The behavior of the compiler is what drives the testsuite?!  The testsuite doesn't exist to test other than the behavior of the compiler we would like to see.  By defining the behavior of the compiler we'd like to see, we define exactly what we want to test.  If we can't agree on the compiler, then by definition, we can't agree on the testsuite.  So, first things first, we have to resolve the features in the compiler, so that we know in what direction we are traveling.

If you disagree, you'd have to enlighten me what purpose the testsuite serves.  I'm happy to listen.

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

If the testsuite can paper over configuration bits that are wrong, and re-adjust the compiler, but, the compiler can't, then you wind up with testsuite results that don't reflect the expected runtime behavior of the compiler.  The testsuite tries to reproduce the environment that the compiler will see when the user uses it, so as to as faithfully as it can test the compiler, as the user will see it. It is an obligation for the user to provide the environment the compiler is to be used in to the compiler during build and test.

>> Do you think it works perfectly and needs no changing in this area
> I think the compiler is working just fine.

Ah, then I'd leave you and Jakub to sort out if the linker should use the plugin by default when the plugin just isn't going to work...  I think he preferred to fix the compiler to not enable the plugin by default in this case.  This why agreement on the behavior of the compiler is critical.

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

Validating the the linker 64-bitness matches the plugin 64-bitness in addition to validating the version number.

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

If I understand what you just said, I disagree.  The environment provided to configure, is the final environment, it is what is actually available, it is the one from which to make all decisions.  If the user doesn't like that, then the user is free to more faithfully provide the environment.

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

Odd.  So, does the compiler enable by default the plug-in when it can know that the plug-in isn't going to work?  I thought the entire point was that the compiler was using the plug-in and that plug-in wasn't working?

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

Jakub said disable by default, and I'm just going along with that as a given.  Since I agree with his position as well, I'd find it hard to argue against it.  If you want other than that, you'd have find support for that position.

gcc builds for the environment provided.  Sorry if you don't agree with that.  The reason why we do this is, gcc takes as gospel what you say.  If you say you have a 64-bit linker, then, you have a 64-bit linker.  If you say you have a 32-bit linker, then you have a 32-bit linker.  When you say you have a 64-bit linker, it isn't going to assume that you have a 32-bit linker.

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

We can test, and we do test.  What is available as build time, is what is available at run time.  There isn't 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 the failures that are observed are the same failures the user would see in using the compiler, then, I disagree with you, it is appropriate to show the failures.  If the user doesn't see the failures, then I would agree with you.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]