Re: gcc 4.3.0 i386 default question

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

David Edelsohn wrote:
> > > > > > Joel Sherrill writes:
> > > > > >             
>
> Joel> If I understand this correctly, it is checking that the
> Joel> target HW actually supports the Neon extension.
> Joel> Is this right?
>
> Joel> Where does this get invoked?
>
> Joel> I think I am on the edge of understanding a solution
> Joel> path.  It sounds like I need to add similar ones
> Joel> for MMX, SSE,  Altivec, and any other odd multilib
> Joel> CPU option that the test suite hits and a particular
> Joel> target CPU does not support.  Right?
>
>         These already exist for Altivec, but for some reason your testing
> harness is not reporting back failure correctly to disable the tests for
> PowerPC.  See
>
> .../gcc/testsuite/lib/target-supports.exp
>
> check_effective_target_powerpc_altivec
> check_effective_target_powerpc_altivec_ok
> check_vmx_hw_available
>
>   
Those all look like checks to see if the compiler itself
supports Altivec -- not a run-time check on the hardware
like the Neon check_effective_target_arm_neon_hw appears
to be.

The RTEMS targets have a lot of multilibs so it is very likely
that the compiler itself supports options not available
on the hardware platform running the tests. 
>         i?86 does not seem to have as many checks.
>   
I think that is the crux of the issues.  There are cases where
there need to be run-time checks for target hw supporting
a particular feature.

So after some successful grep'ing... is this what is required.

+ Add run-time hw tests for MMX, SSE, and Altivec to
   target-supports.exp

+ Augment gcc.dg/vect/vect.exp to check a few more cases.

Is that the general plan?
> David
>
>   
--joel