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