Re: dg-skip-if on powerpc when multiple cpu cflags specified

[Mark Mitchell <mark at codesourcery dot com>]

Janis Johnson wrote:

> > This will involve editing every test that using dg-options
> > to add a -mcpu/-march flag.  Would it make sense to let
> > dg-options check for the conflict as it adds an option?
>
> Yes, it would meaning adding the new option to hundreds of tests,
> but that's better than the earlier suggestion of adding a very
> ugly dg-skip-if to every one of those tests.

I think it's even more complicated.  The testsuite should not assume 
that options explicitly provided (a combination of the options 
explicitly in the test, those implicitly for the DejaGNU harness, those 
for the multilib being tested, and those provided in the board file) are 
those that govern completely.  In particular, the --with-cpu 
configuration option, or other bits of configury, or -t options that 
serve as abbreviations for other options can all affect what CPU is 
actually being targeted.  Trying to scan the list of options to see 
which ones are provided is too error-prone.

Therefore I think there are two plausible approaches:

1. Make these tests say something about what capability they require, 
with a dg-require directive, and then write autoconf-style tests run by 
the testsuite to determine whether the current compiler has that 
capability.  For example, add a "dg-require-hard-float" directive, and 
probe the compiler to see whether it can generate hard float, given all 
the options in play.

2. Write the tests with #ifdef's that test compiler predefines that 
indicate the CPU model, architecture, or available feature.  For 
example, it would be a nice thing if something like __GNU_CPU_y__ and 
__GNU_TUNE_z__ were defined on all machines, corresponding to -march= 
and -mtune=.  For example __GNU_CPU_603__ for a Power 603, or 
__GNU_FEATURE_ALTIVEC__ for a CPU with AltiVec support, or something.


--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713