s390: testsuite: Fix zero_bits_compound-1.c

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.

gcc/testsuite/ChangeLog:

	* gcc.dg/zero_bits_compound-1.c: Fix for s390.

diff --git a/gcc/testsuite/gcc.dg/zero_bits_compound-1.c b/gcc/testsuite/gcc.dg/zero_bits_compound-1.c
index e71594911b2a4685b8e81575b200dc0772b271bb..f1e267e0fb0f4facd9d6763ef23057faf0cad725 100644 (file)
--- 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*-*-* } } } } */