Re: [testsuite] skip ARM tests with conflicting options

[Richard Earnshaw <rearnsha@arm.com>]

On 10/06/11 01:04, Janis Johnson wrote:
> On 06/08/2011 03:39 AM, Richard Earnshaw wrote:
>> On 08/06/11 03:14, Janis Johnson wrote:
>>> On 06/07/2011 06:25 PM, Mike Stump wrote:
>>>> On Jun 7, 2011, at 4:24 PM, Janis Johnson wrote:
>>>>> On 06/07/2011 02:07 PM, Joseph S. Myers wrote:
>>>>>> On Tue, 7 Jun 2011, Janis Johnson wrote:
>>>>>>
>>>>>>> Several tests in gcc.target/arm use dg-options with -mcpu=xxxx, which
>>>>>>> causes compiler warnings or errors when the multilib flags include
>>>>>>> -march=yyyy.  This patch causes those tests to be skipped.  It also
>>>>>>> prevents gcc.target/arm/20090811-1.c from running with multilibs that
>>>>>>> would override -mcpu or -mfloat-abi options specified for the test.
>>>>>>
>>>>>> I think you should allow compatible -march options - for example, if 
>>>>>> dg-options has -mcpu=cortex-a8, allow -march=armv7-a but disallow all 
>>>>>> other -march options.
>>>>>>
>>>>> Is this one OK?
>>>>
>>>> Not sure if the arm people want to review this or would rather I review it...
>>>>
>>>> Let's give the arm folks a couple days to comment, if no objections, Ok.
>>>>
>>>> A point of warning, eventually, you'll discover that when a compiler defaults to the argument you want to skip, that you'll needs slightly more power to skip them.  darwin ran into this with things like -m64, and eventually had to do something like lp64.  configure options like --with-cpu=arm9 are the sort that can change the default.
>>>
>>> Yes, I hope to hear from ARM people.
>>>
>>> On ARM, the default from --with-cpu= is overridden by -march at
>>> compile so it's not a problem for this particular set of tests.
>>> As I said originally, this set is the tip of the iceberg and they
>>> get more difficult.
>>>
>>> Janis
>>>
>>>
>>
>>
>> I'm worried by this whole approach of command-line checking.  It works,
>> just about, for testsuite variations set with target_list, but it won't
>> work with options used to configure the compiler (eg --with-mode=thumb,
>> or --with-cpu=...).  Perhaps a better approach would be a new dg- test
>> that built a trivial file with all the options and disabled the test if
>> that test failed for any reason.  Something like:
>>
>> dg-target-compatible (target, <compile|link>, additional-opts)
>>
>> The test is only performed if target matches the current target.
>>
>> I'm not sure if this is something that can be easily cached (well, it
>> might be possible if you could index off additional-opts and the default
>> opts), so it might be that this test has to be re-run every time there
>> is a test that needs it.
>>
>> R.
> 
> As I said earlier, the testsuite already provides effective-target support
> that checks for complicated things and it's easy enough to add more.
> 
> Given that there are lots of spurious failures right now due to tests
> being compiled with conflicting options, or during dg-final checks when the
> expected code isn't being generated because multilib options override the
> ones given in the test, is this patch to skip tests using -mcpu if the
> multilibs use -march OK?  I have made the change Joseph suggested to allow
> -march values that do not conflict.
> 
> Expect lots more of these patches, with perhaps different solutions for
> different tests.
> 

Don't get me wrong, I wasn't objecting to the patch as it is (it's a
useful step forward).  I'm just raising a concern that I don't think
it's a total solution.

Janice, I haven't done it, but a compiler built with --with-mode=thumb
would be a useful test to run.

R.