This is the mail archive of the
mailing list for the GCC project.
Re: [Patch ARM/testsuite 00/22] Neon intrinsics executable tests
- From: Ramana Radhakrishnan <ramana dot radhakrishnan at arm dot com>
- To: gcc-patches at gcc dot gnu dot org
- Date: Fri, 06 Jun 2014 16:57:33 +0100
- Subject: Re: [Patch ARM/testsuite 00/22] Neon intrinsics executable tests
- Authentication-results: sourceware.org; auth=none
- References: <1402005882-31597-1-git-send-email-christophe dot lyon at linaro dot org> <Pine dot LNX dot 4 dot 64 dot 1406052330100 dot 6944 at digraph dot polyomino dot org dot uk> <CAKdteOaWKeLZ18AOyV0dKKrQcMMZwzL+p1W2Vu-eq-vvCh9gzw at mail dot gmail dot com>
On 06/06/14 15:40, Christophe Lyon wrote:
On 6 June 2014 01:32, Joseph S. Myers <firstname.lastname@example.org> wrote:
Have these been tested for both big and little endian (especially for
tests where memory layout matters - load / store / lane number tests -
remembering that GNU C vector initializers always use array ordering,
which is not the same as the architecture-defined lane numbering for big
I did run the tests on armeb-none-linux-gnueabihf (with qemu), and in
addition to the FAILs I already mentionned I can see errors in the
vzip and vuzp tests.
At this stage I don't know if it's a bug in my tests or a compiler bug.
Didn't Alan recently fix a bug for big-endian in vzip / vuzp ?
However my tests initialize vectors using vld1, not vector
initializers so I think there shouldn't be this problem.