This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc 4.3.0 i386 default question

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



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

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

Is that the general plan?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]