This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch,testsuite,avr]: Filter-out -mmcu= from options for tests that set -mmcu=
- From: Mike Stump <mikestump at comcast dot net>
- To: Georg-Johann Lay <avr at gjlay dot de>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, Denis Chertykov <chertykov at gmail dot com>, Senthil Kumar Selvaraj <senthil_kumar dot selvaraj at atmel dot com>, Pitchumani Sivanupandi <pitchumani dot sivanupandi at microchip dot com>
- Date: Thu, 1 Dec 2016 08:40:28 -0800
- Subject: Re: [patch,testsuite,avr]: Filter-out -mmcu= from options for tests that set -mmcu=
- Authentication-results: sourceware.org; auth=none
- References: <b5763488-183d-379c-81f1-5bdbe70b696f@gjlay.de>
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.