Re: gcc 4.3.0 i386 default question

[Paul Brook <paul at codesourcery dot com>]

On Wednesday 12 March 2008, Joel Sherrill wrote:
> Paul Brook wrote:
> >> Since we are talking 100s of tests, it seems like it would be
> >> easiest to avoid them in the scripts. I just don't know how
> >> to do that.
> >
> > You might want to look at how the ARM NEON vector unit is handled
> > (check_effective_target_arm_neon_ok and
> > check_effective_target_arm_neon_hw).
>
> If I understand this correctly, it is checking that the
> target HW actually supports the Neon extension.
> Is this right?

Yes.  If the test application succeeds we know we can run NEON code. If it 
explodes we can't.

> Where does this get invoked?

I don't know offhand. grep is your friend :-)

> I think I am on the edge of understanding a solution
> path.  It sounds like I need to add similar ones
> for MMX, SSE,  Altivec, and any other odd multilib
> CPU option that the test suite hits and a particular
> target CPU does not support.  Right?

Right. There are three possibilities:

1) The current multilib/test flags are fundmentally incompatible with the 
extension.  In principle there's no reason why you can't have i386+SSE, so 
this probably doesn't apply in your case.

2) Your target nominally supports the extension, however the particular 
hardware used for testing does not.  In this case we want to run all the 
compile tests, but skip the execution tests. Currently there are two ways of 
doing this:
2a) Put a runtime check in every single execute test.  If the extension is not 
present then skip the actual test and pretend we succeeded. This is what x86 
currently does.  However in many cases this is not feasible. e.g. in a bare 
metal environment where the only way to test for a feature is to try it and 
see if your program dies.
3b) Have dejagnu do an execute test. If this fails, then skip all the other 
execute tests.

3) Your target hardware supports the extension. Everything just works.

Paul