Message ID | ZrHnNw/b0CZzclYa@tucnak |
---|---|
State | New |
Headers | show |
Series | testsuite: Fix up pr116037.c test [PR116245] | expand |
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 <jakub@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 > >
--- 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; }