On 06/29/2011 06:55 AM, Richard Earnshaw wrote:
> On 15/06/11 17:38, Janis Johnson wrote:
>> On 06/15/2011 01:13 AM, Ramana Radhakrishnan wrote:
>>> On 14 June 2011 21:35, Janis Johnson <jani...@codesourcery.com> wrote:
>>>> These tests apparently require thumb2 support (I don't yet know much
>>>> about ARM). OK for trunk, and later 4.6?
>>>
>>> OK - The -march=armv7-a is redundant in these tests. You should be
>>> able to lose them if arm_thumb2_ok returns true.
>>
>> That brings up an important point. Without any changes, this test
>> passes scan-assembler when run with multilibs that don't override the
>> -march= option, but fails the scan when -march from multilibs
>> overrides the one from dg-options and doesn't support thumb2. With
>> "dg-require-effective-target arm_thumb2_ok" the test is skipped for
>> multilibs that don't support thumb2, including those that default to an
>> arch that doesn't support it.
>>
>> If we want this and similar tests to continue to be run for default
>> multilibs with default support for older values of -march then instead
>> of using ""dg-require-effective-target arm_thumb2_ok" the test can skip
>> multilibs that use -march that don't support thumb2, e.g.
>>
>> /* { dg-skip-if "need thumb2" { arm*-*-* } { "-march=*" } { "-march=armv6t2"
>> "-march=armv[7-9]*" "-march=armv[1-9][0-9]*" } } */
>>
>> In summary, the choice for a test like this is:
>>
>> 1. Provide options needed to test particular functionality, and skip the
>> test if multilib flags that override those options would not test the
>> relevant functionality.
>> 2. Skip the test if multilib options on their own do not provide the
>> functionality that the test covers.
>>
>
> I'd posit a third option:
>
> 3. Add a new dg directive (perhaps dg-ignore-multilib) that instructs
> the framework to ignore the multilib options entirely (only supported
> for compile/assembly tests).
>
> There are a lot of target-specific tests that are not really testing
> execution, just that the compiler generates the right instruction under
> specific compilation options. It seems silly to force all this into the
> multi-lib framework.
>
> R.
The MIPS tests have support for something like that that, but it seems
to me that if tests are being run for lots of multilibs then it's
better to test things like code generation for a variety of relevant
options instead of using the same options every time.
Having said that, I'm happy that you and other ARM maintainers and
developers are now thinking about how multilibs and dg-options interact
and how you want the tests to be run. My primary goal is to get rid of
spurious failures when we run tests internally with 10 or 12 multilibs.
So far I've been stumbling about trying to skip tests when multilibs
don't support them, but I'll follow whatever approach you guys prefer.
Janis
>> Option 2 assumes that there is enough test coverage for later arch
>> versions, either with default support or multilib options. This choice
>> applies to several tests in gcc.target/arm.
>>
>> Janis
>>
>
