Joel Sherrill wrote:
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.
There's no reason that we can't probe once per multilib. There are
already probes like that in the testsuite. The autoconfy-ness just
needs to be per-multilib.
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?
Just by doing "return 0;" from "main".
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
Here:
#if !defined(__PPC405__)
int main() { return 0; }
#else
/* The real test goes here. */
#endif
Would this work on the scan tests which look for particular
assembly instructions?
Probably not. Though, I suppose:
#if !defined(__PPC405__)
asm("haha here is a 405 insn");
#else
/* The real test goes here. */
#endif
might...
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
