On 13/10/11 00:21, Janis Johnson wrote:
> Tests gcc.target/arm/pr48252.c and gcc.target/arm/neon-vset_lanes8.c
> expect little-endian code and fail when compiled with -mbig-endian.
> This patch skips the test if the current multilib does not generate
> little-endian code.
>
> I'm not able to run execution tests for -mbig-endian for GCC mainline
> but have tested this patch with CodeSourcery's GCC 4.6. OK for trunk?
>
>
> gcc-20111012-003
>
>
> 2011-10-12 Janis Johnson <jani...@codesourcery.com>
>
> * gcc.target/arm/pr48252.c: Require arm_little_endian.
> * gcc.target/arm/neon-vset_lanes8.c: Likewise.
>
> Index: gcc/testsuite/gcc.target/arm/pr48252.c
> ===================================================================
> --- gcc/testsuite/gcc.target/arm/pr48252.c (revision 344214)
> +++ gcc/testsuite/gcc.target/arm/pr48252.c (working copy)
> @@ -1,5 +1,6 @@
> /* { dg-do run } */
> /* { dg-require-effective-target arm_neon_hw } */
> +/* { dg-require-effective-target arm_little_endian } */
> /* { dg-options "-O2" } */
> /* { dg-add-options arm_neon } */
>
I can't think of any obvious reason why this should fail in big-endian.
> Index: gcc/testsuite/gcc.target/arm/neon-vset_lanes8.c
> ===================================================================
> --- gcc/testsuite/gcc.target/arm/neon-vset_lanes8.c (revision 344214)
> +++ gcc/testsuite/gcc.target/arm/neon-vset_lanes8.c (working copy)
> @@ -2,6 +2,7 @@
>
> /* { dg-do run } */
> /* { dg-require-effective-target arm_neon_hw } */
> +/* { dg-require-effective-target arm_little_endian } */
> /* { dg-options "-O0" } */
> /* { dg-add-options arm_neon } */
>
I can see why this fails at present, the test is based on the assumption
that
int8x8_t x = {...}
puts the first element in lane 0 and subsequent elements in consecutive
lanes, *and* that this is equivalent to casting char[8] into a vector.
However, this isn't the case for big-endian.
There's two ways this could be sorted.
1) Change the testcase to:
#include "arm_neon.h"
#include <stdlib.h>
#include <string.h>
signed char x_init[8] = { 1, 2, 3, 4, 5, 6, 7, 8 };
signed char y_init[8] = { 1, 2, 3, 16, 5, 6, 7, 8 };
int main (void)
{
int8x8_t x = vld1_s8(x_init);
int8x8_t y = vld1_s8(y_init);
x = vset_lane_s8 (16, x, 3);
if (memcmp (&x, &y, sizeof (x)) != 0)
abort();
return 0;
}
2) Change the compiler to make initializers of vectors assign elements
of initializers to consecutive lanes in a vector, rather than the
current behaviour of 'casting' an array of elements to a vector.
While the second would be my preferred change, I suspect it's too hard
to fix, and may well cause code written for other targets to break on
big-endian (altivec for example).
R.
