Hi! On Wed, Nov 21, 2018 at 12:07:51PM -0600, Segher Boessenkool wrote: > > Admittedly, it might be better if the initializer was 0x1010101 or say > > 0x4030201 because on big endian in particular 0x10101 has the top 15 bits > > all zero and thus that is what is in u.f1, so if the bug can be reproduced > > with the combine.c + rtlanal.c fix reverted with 0x4030201, it would be > > better to use that value (in both spots). > > Yeah good point.
I've now managed to test this with a cross to armv7hl (scped to an arm box) with and without the rtlanal.c + combine.c change reverted and on powerpc64-linux as example of big-endian, on armv7hl it still fails with the changes reverted, otherwise it succeeds on both. The test also needs 32-bit int target (previously just 17-bit or more, so I've added effective target). Ok for trunk and release branches? 2018-11-21 Jakub Jelinek <ja...@redhat.com> PR rtl-optimization/85925 * gcc.c-torture/execute/20181120-1.c: Require effective target int32plus. (u): New variable. (main): Compare d against u.f1 rather than 0x101. Use 0x4030201 instead of 0x10101. --- gcc/testsuite/gcc.c-torture/execute/20181120-1.c.jj 2018-11-21 17:39:47.963671708 +0100 +++ gcc/testsuite/gcc.c-torture/execute/20181120-1.c 2018-11-21 20:07:45.804556443 +0100 @@ -1,4 +1,5 @@ /* PR rtl-optimization/85925 */ +/* { dg-require-effective-target int32plus } */ /* Testcase by <s...@gcc.gnu.org> */ int a, c, d; @@ -9,17 +10,18 @@ union U1 { unsigned f0; unsigned f1 : 15; }; +volatile union U1 u = { 0x4030201 }; int main (void) { for (c = 0; c <= 1; c++) { - union U1 f = {0x10101}; + union U1 f = {0x4030201}; if (c == 1) b; *e = f.f1; } - if (d != 0x101) + if (d != u.f1) __builtin_abort (); return 0; Jakub