This is the mail archive of the
mailing list for the GCC project.
Re: gcc 4.3.0 i386 default question
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
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
3) Your target hardware supports the extension. Everything just works.