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
[EMAIL PROTECTED]
(650) 331-3385 x713
