Starting with r12-2731-g96146e61cd7aee we do not generate code like _5 = (unsigned int) c_2(D); i_6 = _5 << 8; _7 = _5 << 20; i_8 = i_6 | _7;
anymore but instead _5 = (unsigned int) c_2(D); _3 = _5 * 1048832; which leads finally to slightly different assembly code where we previously ended up for z10 or newer with lr %r1,%r2 sll %r1,8 rosbg %r1,%r2,32,43,20 llgfr %r2,%r1 br %r14 and now lr %r1,%r2 sll %r1,12 ar %r2,%r1 risbg %r2,%r2,35,128+55,8 br %r14 The zero-extend materializes via risbg for which the pattern contains an "and" which is why the test fails. Thus, instead of scanning for RTL expressions rather scan for assembler instructions for s390. --- Ok for mainline? gcc/testsuite/gcc.dg/zero_bits_compound-1.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/gcc/testsuite/gcc.dg/zero_bits_compound-1.c b/gcc/testsuite/gcc.dg/zero_bits_compound-1.c index e71594911b2..f1e267e0fb0 100644 --- a/gcc/testsuite/gcc.dg/zero_bits_compound-1.c +++ b/gcc/testsuite/gcc.dg/zero_bits_compound-1.c @@ -39,4 +39,5 @@ unsigned long bar (unsigned char c) } /* Check that no pattern containing an AND expression was used. */ -/* { dg-final { scan-assembler-not "\\(and:" } } */ +/* { dg-final { scan-assembler-not "\\(and:" { target { ! { s390*-*-* } } } } } */ +/* { dg-final { scan-assembler-not "\\tng?rk?\\t" { target { s390*-*-* } } } } */ -- 2.44.0