Mark Mitchell wrote:
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.
That will not work on at least the *-rtems* configurations.
We use one multilib'ed toolset configuration to support
all variants within a family. So for the PowerPC, we actually
do have support for [4567]xx, [58]xxx, etc. m68k includes
coldfire, etc.
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.
I think this would work. If you ended up with compiler
settings that didn't match what the test required, then
it could exit. How should it exit in this case?
For the case we have been looking at, -mcpu=405 results
in __PPC405__ being defined. If you are writing a CPU model
specific test, you should know what the macro generated is.
#if !defined(__PPC405__)
XXX -- ?? what to do?
#endif
Would this work on the scan tests which look for particular
assembly instructions?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
