Ping #1: [patch,testsuite,avr]: Filter-out -mmcu= from options for tests that set -mmcu=

[Denis Chertykov]

2016-12-13 13:36 GMT+04:00 Georg-Johann Lay <avr@gjlay.de>:
> Ping #1
>
> As I explained below, the solution taken be arm (pruning output)
> does not work here.

Approved.
Please apply your patch.

>
> Johann
>
> On 02.12.2016 11:21, Georg-Johann Lay wrote:
>>
>> On 01.12.2016 17:40, Mike Stump wrote:
>>>
>>> On Dec 1, 2016, at 3:54 AM, Georg-Johann Lay <avr@gjlay.de> wrote:
>>>>
>>>>
>>>> This patch moves the compile tests that have a hard coded -mmcu=MCU
>>>> in their dg-options to a new folder.
>>>>
>>>> The exp driver filters out -mmcu= from the command line options that
>>>> are provided by, say, board description files or --tool-opts.
>>>>
>>>> This is needed because otherwise conflicting -mmcu= will FAIL
>>>> respective test cases because of "specified option '-mmcu' more than
>>>> once" errors from avr-gcc.
>>>>
>>>> Ok for trunk?
>>>
>>>
>>> So, it would be nice if different ports can use roughly similar
>>> schemes to handle the same problems.  I think arm is one of the more
>>> complex ports at this point in this regard with a lot of people and a
>>> lot of years time to contemplate and implement solutions to the
>>> problem.  They in particular don't have to move test cases around to
>>> handle the difference like this, I think it would be best to avoid
>>> that requirement if possible.
>>>
>>> Glancing around, two starting points for how the arm achieves what it
>>> does:
>>>
>>>   lappend dg_runtest_extra_prunes "warning: switch -m(cpu|arch)=.*
>>> conflicts with -m(cpu|arch)=.* switch"
>>>
>>> in arm.exp, and they use something like:
>>>
>>> /* { dg-require-effective-target arm_crypto_ok }
>>> */
>>> |crypto-vsha256hq_u32.c:2:/* { dg-require-effective-target
>>> arm_crypto_ok } */
>>> /* { dg-add-options arm_crypto }
>>> */
>>> |crypto-vsha256su0q_u32.c:2:/* { dg-require-effective-target
>>> arm_crypto_ok } */
>>>
>>> to validate the requirements of the test case, and to ensure that
>>> optional things are selected.  Nice, simple, extensible, handles
>>> multilibs, dejagnu arguments and different cpu defaults as I recall.
>>>
>>> You won't need all the hair the arm folks have, but if you stub in
>>> support in that direction, you then have simple, easy expansion room
>>> to match all complexities that the arm folks have already hit and
>>> solved.
>>
>>
>> I tried this approach, but it does not work as expected.
>>
>> Notice that avr-gcc throws an error if conflicting -mmcu options are
>> supplied.  Pruning the output will make some tests "PASS", but the
>> compiler didn't actually do anything but producing an error message...
>>
>> And one test FAILs because it should produce some specific diagnostic,
>> but again the compiler just throws a different error, the output is
>> pruned and the expected message is missing, hence fail.
>>
>> Also one test case is for ATmega8, but you won't run the whole test
>> suite against ATmega8 because that device is too restricted to give
>> reasonable results...  Hence for some tests -mmcu=atmega8 is added by
>> hand.
>>
>> Johann
>>
>>
>>
>>
>>
>