Ping #1
As I explained below, the solution taken be arm (pruning output)
does not work here.
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
