[Bug target/103149] New: cc1: error: inconsistent operand constraints in an 'asm'

[Bug target/103149] New: cc1: error: inconsistent operand constraints in an 'asm'

[asolokha at gmx dot com]

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

            Bug ID: 103149
           Summary: cc1: error: inconsistent operand constraints in an
                    'asm'
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          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-alpha20211107 snapshot (g:962ff7d2849e1fa6a1fe0535aa2dec5c2b9a32a6)
ICEs when compiling the following testcase w/ -march=armv8-a+sve -O2
-fharden-conditional-branches -fno-tree-scev-cprop:

void
foo (int *p)
{
  while (*p < 1)
    ++*p;
}

% aarch64-linux-gnu-gcc-12.0.0 -march=armv8-a+sve -O2
-fharden-conditional-branches -fno-tree-scev-cprop -c fzbx3mly.c
In function 'foo':
cc1: error: inconsistent operand constraints in an 'asm'

fzbx3mly.c.338t.statistics is the last non-empty dump,
fzbx3mly.c.339t.earlydebug and fzbx3mly.c.340t.debug are indeed empty.

[Bug middle-end/103149] cc1: error: inconsistent operand constraints in an 'asm'

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-11-09

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
  vector([4,4]) <signed-boolean:4> next_mask_10;
  vector([4,4]) <signed-boolean:4> next_mask_28;

 next_mask_28 = .WHILE_ULT (_13, bnd.6_6, { 0, ... });
  if (next_mask_28 != { 0, ... })
    goto <bb 9>; [83.33%]
  else
    goto <bb 11>; [16.67%]
;;    succ:       9
;;                11

;;   basic block 9, loop depth 1
;;    pred:       8
  __asm__("" : "=g" next_mask_10 : "0" next_mask_28);
  if (next_mask_10 == { 0, ... })
    goto <bb 10>; [INV]
  else
    goto <bb 8>; [100.00%]

Confirmed, the problem is harden conditionals insert an inline-asm which is
invalid for a "SVE vector type".  My bet is there are other testcases which can
hit this issue without even -fno-tree-scev-cprop but it definitely is the
easiest way for this testcase.

[Bug middle-end/103149] cc1: error: inconsistent operand constraints in an 'asm' with -fharden-conditional-branches and SVE turned on

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva <aoliva at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |aoliva at gcc dot gnu.org

--- Comment #2 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
Huh, weird, we skip vector types.

Aah, but only in -fharden-compares.

Thanks for the report, will fix.

[Bug middle-end/103149] cc1: error: inconsistent operand constraints in an 'asm' with -fharden-conditional-branches and SVE turned on

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Alexandre Oliva <aoliva@gcc.gnu.org>:

https://gcc.gnu.org/g:0485ce9128f272fe7ccb48672f69d7be6bb26a9c

commit r12-5831-g0485ce9128f272fe7ccb48672f69d7be6bb26a9c
Author: Alexandre Oliva <oliva@adacore.com>
Date:   Sat Dec 4 00:17:18 2021 -0300

    [PR103149] detach values through mem only if general regs won't do

    When hardening compares or conditional branches, we perform redundant
    tests, and to prevent them from being optimized out, we use asm
    statements that preserve a value used in a compare, but in a way that
    the compiler can no longer assume it's the same value, so it can't
    optimize the redundant test away.

    We used to use +g, but that requires general regs or mem.  You might
    think that, if a reg constraint can't be satisfied, the register
    allocator will fall back to memory, but that's not so: we decide on
    matching MEMs very early on, by using the same addressable operand on
    both input and output, and only if the constraint does not allow
    registers.  If it does, we use gimple registers and then pseudos as
    inputs and outputs, and then inputs can be substituted by equivalent
    expressions, and then, if no register contraint fits (e.g. because
    that mode won't fit in general regs, or won't fit in regs at all), the
    register allocator will give up before even trying to allocate some
    temporary memory to unify input and output.

    This patch arranges for us to create and use the temporary stack slot
    if we can tell the mode requires memory, or won't otherwise fit in
    general regs, and thus to use +m for that asm.


    for  gcc/ChangeLog

            PR middle-end/103149
            * gimple-harden-conditionals.cc (detach_value): Use memory if
            general regs won't do.

    for  gcc/testsuite/ChangeLog

            PR middle-end/103149
            * gcc.target/aarch64/pr103149.c: New.

[Bug middle-end/103149] cc1: error: inconsistent operand constraints in an 'asm' with -fharden-conditional-branches and SVE turned on

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva <aoliva at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #4 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
Fixed