On Tue, 6 Aug 2024, Jakub Jelinek wrote:
> Hi!
>
> The test FAILs on big endian targets, because VV is a vector of unsigned
> __int128
> and VC vector of unsigned char and so ((VC) vv)[0] is 0x01 on little endian
> but 0xff on big endian and PDP endian.
> As I believe it is intentional to test it as it is written on little endian,
> the following patch just adds another case for big endian and for other
> endians instead of figuring out what exactly to fetch it fetches the whole
> unsigned __int128 and casts it to unsigned char. Not that pdp11 has
> __int128 support...
>
> Tested on x86_64-linux and powerpc64-linux, ok for trunk?
OK.
> 2024-08-06 Jakub Jelinek <ja...@redhat.com>
>
> PR rtl-optimization/116037
> PR testsuite/116245
> * gcc.dg/torture/pr116037.c (foo): Fix up for big end middle endian.
>
> --- gcc/testsuite/gcc.dg/torture/pr116037.c.jj 2024-07-25
> 21:34:56.190147936 +0200
> +++ gcc/testsuite/gcc.dg/torture/pr116037.c 2024-08-06 10:58:56.621762156
> +0200
> @@ -16,7 +16,13 @@ VL vl;
> VV
> foo (unsigned long long x, VV vv)
> {
> +#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
> x &= -((VC) vv)[0];
> +#elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
> + x &= -((VC) vv)[sizeof (__int128) - 1];
> +#else
> + x &= -(unsigned char) (vv[0]);
> +#endif
> vi *= (VI) (VS){ -vs[0], vc[0], vs[1], vi[7], vs[7], vl[7], x, vi[5] };
> return x + vv;
> }
>
> Jakub
>
>
--
Richard Biener <rguent...@suse.de>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
