[Bug target/101428] New: [10/11/12 Regression] ICE: 'asm' clobber conflict with output operand

[Bug target/101428] New: [10/11/12 Regression] ICE: 'asm' clobber conflict with output operand

[asolokha at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101428

            Bug ID: 101428
           Summary: [10/11/12 Regression] ICE: 'asm' clobber conflict with
                    output operand
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Keywords: ice-on-invalid-code
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: asolokha at gmx dot com
  Target Milestone: ---
            Target: aarch64-linux-gnu

gcc-12.0.0-alpha20210711 snapshot (g:269256f33c51222167ad461f775d5468bb5ecaf5)
ICEs when compiling the following testcase, extracted from
test/CodeGen/inline-asm-x86-flag-output.c from the clang 12.0.0 test suite:

int test_ccge(long nr, volatile long *addr) {
  int x;
  asm("cmp %2,%1"
      : "=@ccge"(x), "=m"(*(volatile long *)(addr))
      : "r"(nr)
      : "cc");
  if (x)
    return 0;
  return 1;
}

% aarch64-linux-gnu-gcc-12.0.0 -c dwwjjifx.c
during RTL pass: expand
dwwjjifx.c: In function 'test_ccge':
dwwjjifx.c:3:3: internal compiler error: 'asm' clobber conflict with output
operand
    3 |   asm("cmp %2,%1"
      |   ^~~
0xa35e46 expand_asm_stmt
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20210711/work/gcc-12-20210711/gcc/cfgexpand.c:3603
0xa3a640 expand_gimple_stmt_1
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20210711/work/gcc-12-20210711/gcc/cfgexpand.c:3874
0xa3a640 expand_gimple_stmt
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20210711/work/gcc-12-20210711/gcc/cfgexpand.c:4041
0xa41036 expand_gimple_basic_block
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20210711/work/gcc-12-20210711/gcc/cfgexpand.c:6083
0xa42de7 execute
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20210711/work/gcc-12-20210711/gcc/cfgexpand.c:6809

(if it really makes sense to file PRs for this type of ICEs, of course.)

[Bug target/101428] [10/11/12 Regression] ICE: 'asm' clobber conflict with output operand

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101428

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.4

[Bug target/101428] [10/11/12 Regression] ICE: 'asm' clobber conflict with output operand

[belagod at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101428

Tejas Belagod <belagod at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |belagod at gcc dot gnu.org
   Last reconfirmed|                            |2021-07-21
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Tejas Belagod <belagod at gcc dot gnu.org> ---
Is it legal to let the flag output operand '=@ccge' overlap with the
corresponding clobbered operand 'cc'? As a general rule, the extended asm spec
says I/O operands can't overlap with the clobber list -
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Clobbers-and-Scratch-Registers.

Also, CMP on AArch64 does not have a form that matches with "=m" constraint for
the output. So I don't think its valid code, but the compiler shouldn't ICE,
therefore confirmed as a bug.

[Bug target/101428] [10/11/12 Regression] ICE: 'asm' clobber conflict with output operand

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101428

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
varasm.cc does

          /* Do sanity check for overlap between clobbers and respectively
             input and outputs that hasn't been handled.  Such overlap
             should have been detected and reported above.  */
          if (!clobber_conflict_found && REG_P (clobbered_reg))
            {
              /* We test the old body (obody) contents to avoid
                 tripping over the under-construction body.  */
              for (unsigned k = 0; k < noutputs; ++k)
                if (reg_overlap_mentioned_p (clobbered_reg, output_rvec[k]))
                  internal_error ("%<asm%> clobber conflict with "
                                  "output operand");

              for (unsigned k = 0; k < ninputs - ninout; ++k)
                if (reg_overlap_mentioned_p (clobbered_reg, input_rvec[k]))
                  internal_error ("%<asm%> clobber conflict with "
                                  "input operand");
            }

so the comment suggests it was expected to be diagnosed in a friendlier way
but appearantly that didn't work out.  Was this ever working or why is this
marked as regression?

[Bug target/101428] [10/11/12 Regression] ICE: 'asm' clobber conflict with output operand

[asolokha at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101428

--- Comment #3 from Arseny Solokha <asolokha at gmx dot com> ---
(In reply to Richard Biener from comment #2)
> Was this ever working or why is this
> marked as regression?

gcc 9 and earlier accept the code w/o any diagnostic, and AFAICT the snippet
you quoted had been changed last time in r223025.

[Bug target/101428] [10/11/12 Regression] ICE: 'asm' clobber conflict with output operand

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101428

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
GCC 9 emitted it as:
(reg:SI 95 [ x ])
                (asm_operands:SI ...

While GCC 10 would emit it as:
            (set (reg:CC 66 cc)
                (asm_operands:CC

[Bug middle-end/101428] ICE: 'asm' clobber conflict with output operand with CC output and "CC" clobber

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101428

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |middle-end
             Target|aarch64-linux-gnu           |aarch64*-* arm*-*
            Summary|[10/11/12 Regression] ICE:  |ICE: 'asm' clobber conflict
                   |'asm' clobber conflict with |with output operand with CC
                   |output operand              |output and "CC" clobber
   Target Milestone|10.4                        |---

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This is not a regression as the CC mode output was not supported before GCC 10.
It was added with r10-4658.

I don't know why it was not rejected in GCC 9 though.

Note you can reproduce the ICE with just:
int test_ccge(long nr, long t) {
  int x;
  asm("cmp %1,%1"
      : "=@ccge"(x)
      : "r"(nr), "r"(t)
      : "cc");
  return x;
}

Which is closer to legal still.  Removing the cc clobber fixes the issue.
Note you should be able to produce the ICE on arm too (arm and aarch64 share
some backend code and this is one case it shares).

We do have some code which does check for the conflict but it does not use the
adjusted values but the original tree ones:
  /* Third pass checks for easy conflicts.  */
  /* ??? Why are we doing this on trees instead of rtx.  */

  bool clobber_conflict_found = 0;
  for (i = 0; i < noutputs; ++i)
    if (tree_conflicts_with_clobbers_p (output_tvec[i], &clobbered_regs,
locus))
        clobber_conflict_found = 1;
  for (i = 0; i < ninputs - ninout; ++i)
    if (tree_conflicts_with_clobbers_p (input_tvec[i], &clobbered_regs, locus))
        clobber_conflict_found = 1;