]> git.ipfire.org Git - thirdparty/gcc.git/commit
s390: Replace some checking assertions with output_operand_lossage [PR118511]
authorJakub Jelinek <jakub@redhat.com>
Fri, 17 Jan 2025 18:27:59 +0000 (19:27 +0100)
committerJakub Jelinek <jakub@gcc.gnu.org>
Fri, 17 Jan 2025 18:27:59 +0000 (19:27 +0100)
commit71280df05f28fd568f8b863dd700c0be2f2443a8
treeccb7a4659576f44fc83b025d612a5dae7c6fb34b
parent26b2d9f27ca24f0705641a85f29d179fa0600869
s390: Replace some checking assertions with output_operand_lossage [PR118511]

r15-2002 s390: Fully exploit vgm, vgbm, vrepi change added
some code to print_operand and added gcc_checking_asserts in there.
But print_operand ideally should have no assertions in it, as most
of the assumptions can be easily violated by people using it in
inline asm.
This issue in particular was seen by failure to compile s390-tools,
which had in its extended inline asm uses of %r1 and %r2.
I really don't know if they meant %%r1 and %%r2 or %1 and %2 and
will leave that decision to the maintainers, but the thing is that
%r1 and %r2 used to expand like %1 and %2 in GCC 14 and earlier,
now in checking build it ICEs and in --enable-checking=release build
fails to assemble (the checking assert is ignored and the compiler just uses
some uninitialized variables to emit something arbitrary).

With the following patch it is diagnosed as error consistently
regardless if it is release checking or no checking or checking compiler.

Note, I see also
      else if (GET_CODE (x) == UNSPEC && XINT (x, 1) == UNSPEC_TLSLDM)
        {
          fprintf (file, "%s", ":tls_ldcall:");
          const char *name = get_some_local_dynamic_name ();
          gcc_assert (name);
          assemble_name (file, name);
        }
in print_operand, maybe that isn't a big deal because it might be
impossible to construct inline asm argument which is UNSPEC_TLSLDM.
And then there is
        case 'e': case 'f':
        case 's': case 't':
          {
            int start, end;
            int len;
            bool ok;

            len = (code == 's' || code == 'e' ? 64 : 32);
            ok = s390_contiguous_bitmask_p (ival, true, len, &start, &end);
            gcc_assert (ok);
            if (code == 's' || code == 't')
              ival = start;
            else
              ival = end;
          }
          break;
which likely should be also output_operand_lossage but I haven't tried
to reproduce that.

2025-01-17  Jakub Jelinek  <jakub@redhat.com>

PR target/118511
* config/s390/s390.cc (print_operand) <case 'p'>: Use
output_operand_lossage instead of gcc_checking_assert.
(print_operand) <case 'q'>: Likewise.
(print_operand) <case 'r'>: Likewise.

* gcc.target/s390/pr118511.c: New test.
gcc/config/s390/s390.cc
gcc/testsuite/gcc.target/s390/pr118511.c [new file with mode: 0644]