Re: [testsuite] skip ARM tests with conflicting options

[Janis Johnson <janisjo@codesourcery.com>]

On 06/10/2011 03:00 AM, Richard Earnshaw wrote:
> 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.

It isn't.

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

There's effective-target support for the following:

  arm32
  arm_vfp_ok
  arm_hard_vfp_ok
  arm_thumb1_ok
  arm_thumb2_ok
  arm_neon_ok
  arm_neon_fp16_ok
  arm_iwmmxt_ok

They check that adding appropriate flags (to be added by dg-options
later in the test) results in expected macros being defined and no
compiler errors or warnings.  Some need additional checks for flags
from multilibs that will override options to be used in tests, as with
my changes for arm_neon_fp16_ok.

If there are tests that fail now with a compiler configured using
--with-mode=thumb because they expect arm mode then the tests should
probably be checking that arm mode is used (arm32 does that) or using
-marm.

In case it isn't obvious, I'm still learning what all the ARM options
are and what they mean, so I might say some really dumb things and hope
that you guys will set me straight.

Janis