Re: [testsuite] skip ARM tests with conflicting options

[Janis Johnson <janisjo@codesourcery.com>]

On 06/08/2011 12:30 PM, Mike Stump wrote:
> On Jun 8, 2011, at 8:28 AM, Janis Johnson wrote:
>> The big question is whether such a test should be run for all multilibs
>> that might possibly pass the test, or only for default and for mulitlibs
>> that provide the same options.
> 
> Here, reasonable people may disagree.  I suspect in the end, we'll have
> both solutions, and then individual testcases will make their own decision.
> A collection of testcases will tend to follow the same convention...  So, for 
> objective-c, we face the same sort of issue, and we do what we do, and that isn't
> necessarily going to match exactly what for example the gcc.arm does, nor I suspect
> are we going to change just because gcc.arm changes.  I think it makes sense to
> cache as much as possible and skip conflicts.  Taking off my testsuite maintainer
> hat, I think soft conflicts with defaults should mean we run it, and punch in the
> options we want.  If there is something that prohibits that from working (hard
> conflict), it should be skipped.  Feel free to ignore this, as I don't know that
> this is the best answer.

I agree that the answer will be different for different tests.

The problem is that in the case of a "soft conflict", the multilib options
go at the end of the compile line and override the options given in the
test via dg-options.  That's OK if dg-options is providing defaults for when
there is no similar option in the multilib options, but a problem if the test
depends on the flags from dg-options being used, as when a dg-final checks
for specific code generation.  Then we have the choice of running the test
only with the specific values specified in the test, or allowing a range of
values, for mfpu or march or whatever; that gets trickier but we have the
tools to do it.

> I'd like to think that dg-skip-if and dg-require-effective-target and general
> target selection is beefy enough to do everything we need it to, or can be made to.

Right, it's easy to add new effective targets, I don't think we need new test
directives.

Janis