On Aug 25, 2026, Alexandre Oliva <[email protected]> wrote:
> Tested on x86_64-linux-gnu, ppc-elf and leon3-elf. I'm tempted to put
> it in as obvious, but just in case someone would rather fix it
> differently... Ok to install?
Hmm, that would presumably still fail on mixed-endian systems.
How about this? It requires either be or le, so that sso can be
expected to work and bring about the desired result.
The pr126650.c testcase carries an expectation that the data
structures are little endian; we don't get the expected results
otherwise. Make the nonscalars explicitly little-endian.
Retested on x86_64-linux-gnu and ppc-elf. Ok?
for gcc/testsuite/ChangeLog
PR tree-optimization/126650
* gcc.dg/torture/pr126650.c: Be explicit about endianness
expectations.
---
gcc/testsuite/gcc.dg/torture/pr126650.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/torture/pr126650.c
b/gcc/testsuite/gcc.dg/torture/pr126650.c
index 166705d9cfe6d..befeba5259a4f 100644
--- a/gcc/testsuite/gcc.dg/torture/pr126650.c
+++ b/gcc/testsuite/gcc.dg/torture/pr126650.c
@@ -1,4 +1,4 @@
-/* { dg-do run } */
+/* { dg-do run { target { le || be } } } */
#include <stdarg.h>
#include <stdlib.h>
@@ -17,14 +17,14 @@ void __attribute__((noipa)) foo (int n, ...)
int main()
{
- struct b {
+ struct __attribute__ ((scalar_storage_order ("little-endian"))) b {
int : 7;
int : 2;
int : 6;
int : 3;
int c : 7;
};
- union {
+ union __attribute__ ((scalar_storage_order ("little-endian"))) {
int d;
struct b bf;
char e[4];
--
Alexandre Oliva, happy hacker https://blog.lx.oliva.nom.br/
Free Software Activist FSFLA co-founder GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity.
Excluding neuro-others for not behaving ""normal"" is *not* inclusive!
