Re: marking ppc440 tests as unsupported

2009-01-12 Thread Joel Sherrill
Joseph S. Myers wrote: On Mon, 12 Jan 2009, Joel Sherrill wrote: The unfortunate thing is that I think these tests are really ensuring that MASK_DLMZB is used as expected. If this is right, then shouldn't there be a cpp predefine similar to __NO_LWSYNC__ for dlmzb? And the tests use that r

Re: marking ppc440 tests as unsupported

2009-01-12 Thread Joseph S. Myers
On Mon, 12 Jan 2009, Joel Sherrill wrote: > The unfortunate thing is that I think these > tests are really ensuring that MASK_DLMZB is > used as expected. If this is right, then > shouldn't there be a cpp predefine similar > to __NO_LWSYNC__ for dlmzb? And the tests use > that rather than testin

Re: marking ppc440 tests as unsupported

2009-01-12 Thread Daniel Jacobowitz
On Mon, Jan 12, 2009 at 10:10:18AM -0600, Joel Sherrill wrote: > The unfortunate thing is that I think these > tests are really ensuring that MASK_DLMZB is > used as expected. If this is right, then > shouldn't there be a cpp predefine similar > to __NO_LWSYNC__ for dlmzb? And the tests use > tha

marking ppc440 tests as unsupported

2009-01-12 Thread Joel Sherrill
Hi, With the help of Janis, the ppc405 tests can now detect when the scan assembler won't pass. I moved on to do the same with the ppc440 tests and noticed that there is no cpp predefine to know when you are compiled for a ppc440. $ powerpc-rtems4.10-gcc -mcpu=440 -E - -dM 440 $ powerpc-rtems4.1