https://gcc.gnu.org/g:df4062c54b0b3c5f5c6a1f1a2454abf965100e3a

commit r15-2753-gdf4062c54b0b3c5f5c6a1f1a2454abf965100e3a
Author: Jakub Jelinek <ja...@redhat.com>
Date:   Tue Aug 6 11:52:35 2024 +0200

    testsuite: Fix up pr116037.c test [PR116245]
    
    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...
    
    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.

Diff:
---
 gcc/testsuite/gcc.dg/torture/pr116037.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/gcc/testsuite/gcc.dg/torture/pr116037.c 
b/gcc/testsuite/gcc.dg/torture/pr116037.c
index 86ab50de4b2f..5bab24107fc2 100644
--- a/gcc/testsuite/gcc.dg/torture/pr116037.c
+++ b/gcc/testsuite/gcc.dg/torture/pr116037.c
@@ -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;
 }

Reply via email to