2016-12-13 13:36 GMT+04:00 Georg-Johann Lay <a...@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 <a...@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 >> >> >> >> >> >