On Thu, 2008-04-24 at 18:14 -0500, Joel Sherrill wrote:
> Janis Johnson wrote:
> > On Thu, 2008-04-24 at 17:54 -0500, Joel Sherrill wrote:
> >
> >
> >> Not knowing the internal details of the test harness, I
> >> would make an ignorant guess that the command line
> >> should be checked before it is executed. If it has multiple
> >> -mcpu/-march options and they were not all the same, the
> >> test should be skipped.
> >>
> >> Is that kind of the logic we need even if the implementation
> >> is way off?
> >>
> >
> > When you put it that way it sounds very simple!
> It is easy to say. :-D
> > Something like
> >
> > /* { dg-options "-mcpu=xxx" } */
> > /* { dg-skip-if-incompatible-options } */
> >
> > where dg-skip-if-incompatible-options starts out by looking for
> > multiple instances of non-identical -mcpu= or -march= and then
> > gets refined over time. There's already code in check_flags in
> > target-supports-dg.exp to gather together all the various flags
> > that will be used for a test.
> >
> >
> 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 wouldn't want to change the meaning of dg-options to have it
start skipping tests.
> In my case, the options are added in the board file
> this way:
>
> set_board_info cflags "-B${RTEMS_MAKEFILE_PATH}/lib/ -specs bsp_specs
> -qrtems -mcpu=603e"
Those options are in a data structure that directives like
dg-skip-if already look at.
> > I'll investigate.
> >
> >
> Thanks. This is really a precision fix. :-D
Yeah, well, maybe a more elegant idea will arise to take its
place.
By the way, I won't have anything for a few days since I'll
be spending the next three days doing very non-computer stuff.
Janis
