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

[Joel Sherrill <joel dot sherrill at oarcorp dot com>]

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
> mark@codesourcery.com
> (650) 331-3385 x713
>   


--
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available             (256) 722-9985