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

[Alexandre Oliva]

[Adding gcc@]

On Jun 26, 2012, "H.J. Lu" <hjl.tools@gmail.com> wrote:

> On Tue, Jun 26, 2012 at 3:39 PM, Mike Stump <mikestump@comcast.net> wrote:
>> On Jun 26, 2012, at 2:04 PM, Alexandre Oliva wrote:
>>> I test i686-linux-gnu in a presumably unusual setting
>> 
>> I like the setup and testing...
>> 
>>> This worked fine for regression testing, but I've recently realized
>>> (with the PR49888/53671 mishap) that I'm getting tons of LTO testsuite
>>> failures (before and after, so no regression), because the 32-bit LTO
>>> plugin built in this setting can't possibly be used by the 64-bit linker
>>> installed on the system.  Obviously, passing -melf_i386 to the linker
>>> through the wrapper is not enough for it to be able to dlopen a 32-bit
>>> plugin ;-)

>> So, let's kick this back to the gcc list for all the interested
>> parties to chime in on...  I'd rather have 5 interested people
>> architect the right, nice solution that is engineered to work and
>> then use it.

>> H.J.'s solution seems like the most reasonable short term solution

It's not a “solution”, it's just the same local arrangement I mentioned
I was leaning towards, after fixing the problem in the test harness,
that lets GCC use the plugin and fail even after explicitly testing for
that.  I don't see how that can possibly be perceived as not a bug.
Which is not to say that there aren't *other* bugs in place, and that
some of them might alleviate this one.

>> If we build the plugin after sensing the 64-bitness of ld, using the
>> flags appropriate for the linker...

Then we'd be disobeying the host setting specified or detected by
configure.

>> failing the build early when mismatched

Why?  We don't demand a working plugin.  Indeed, we disable the use of
the plugin if we find a linker that doesn't support it.  We just don't
account for the possibility of finding a linker that supports plugins,
but that doesn't support the one we'll build later.

> Bootstrap/test -m32/-mx32 with LTO on -m64 is similar to cross-compile,
> in the sense that the native linker may not work with plugin.  We just
> need to make the right linker available to GCC. My kludge uses PATH.
> One can also include binutils source in GCC source tree.

These are all reasonable suggestions to make the plugin work.  But
that's not what the patch addresses, namely what to do during testing
when the plugin is found to NOT work.

As I wrote in the original post, even if we were to detect that the
plugin is not supported and refrain from building it and testing it,
it's more valuable that the test summaries explicitly indicate, in each
FAIL or XFAIL, that the plugin was not used, rather than make room for
uncertainty as to whether the plugin was implicitly used or not.

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