On Tue, Aug 25, 2026 at 11:05:04AM +0200, Jakub Jelinek wrote:
> On Tue, Aug 25, 2026 at 09:35:03AM +0200, Andreas Schwab wrote:
> > On Aug 25 2026, Andrea Pinski wrote:
> >
> > >> diff --git a/gcc/testsuite/gcc.dg/torture/pr126650.c
> > >> b/gcc/testsuite/gcc.dg/torture/pr126650.c
> > >> index 166705d9cfe..f9997b16f2b 100644
> > >> --- a/gcc/testsuite/gcc.dg/torture/pr126650.c
> > >> +++ b/gcc/testsuite/gcc.dg/torture/pr126650.c
> > >> @@ -1,5 +1,13 @@
> > >> /* { dg-do run } */
> > >>
> > >> +#if __s390__
> > >
> > > I think this should be `__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__` instead.
> >
> > No, it needs to depend on BITS_BIG_ENDIAN. Byte order and bit order are
> > independent, and gcc supports all combinations of them (the latter is
> > usually constant even if the former is selectable).
>
> Wouldn't it be better to
> 1) guard the test on #if __SIZEOF_INT__ == 4 && __CHAR_BIT__ == 8
> 2) compare the value against something computed surely at runtime,
> e.g. move the struct/union to file scope, add another variable (perhaps
> volatile) outside of main and initialize with { .e[3] = 7 } and pass as
> first argument to foo g.bf.c?
Bit-fields are ABI dependent, i.e., even on big endian architectures
they may differ. Maybe all supported big endian targets align here? My
initial intend was to keep the change as simple as possible for this
single test case. Especially since I didn't come up with the test and
with any change I also potentially break what the test is supposed to
test. Anyhow, I think you are right and sizeof int etc. needs to be
taken into account if more targets are to be considered.
Cheers,
Stefan
