[Bug libgomp/97532] New: Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196

[Bug libgomp/97532] New: Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196

[vries at gcc dot gnu.org]

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

            Bug ID: 97532
           Summary: Error: insn does not satisfy its constraints, internal
                    compiler error: in extract_constrain_insn, at
                    recog.c:2196
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgomp
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vries at gcc dot gnu.org
                CC: jakub at gcc dot gnu.org
  Target Milestone: ---

At commit c26d7df1031 "OpenMP: Fortran - support omp flush's memorder clauses"
I'm seeing a few new FAILs with nvptx offloading:
...
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O1  (internal compiler error)
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O1  (test for excess errors)
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O2  (internal compiler error)
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O2  (test for excess errors)
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler
error)
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O3 -g  (internal compiler error)
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O3 -g  (test for excess errors)
FAIL: libgomp.fortran/examples-4/simd-2.f90   -Os  (internal compiler error)
FAIL: libgomp.fortran/examples-4/simd-2.f90   -Os  (test for excess errors)
...

In more detail:
...
/home/vries/oacc/trunk/source-gcc/libgomp/testsuite/libgomp.fortran/examples-4/simd-2.f90:19:0:
Error: insn does not satisfy its constraints:^M
(insn 76 75 82 2 (set (reg:V8DF 20 xmm0 [orig:153 vect_c_20.334 ] [153])^M
        (plus:V8DF (reg:V8DF 20 xmm0 [orig:184 vect__17.333 ] [184])^M
            (vec_duplicate:V8DF (mem:DF (reg:DI 24 xmm4 [189]) [6 *fact_18(D)+0
S8 A64]))))
"/home/vries/oacc/trunk/source-gcc/libgomp/testsuite/libgomp.fortran/examples-4/simd-2.f90":18:0
1569 {*addv8df3}^M
     (nil))^M
during RTL pass: reload^M
/home/vries/oacc/trunk/source-gcc/libgomp/testsuite/libgomp.fortran/examples-4/simd-2.f90:19:0:
internal compiler error: in extract_constrain_insn, at recog.c:2196^M
0x6092d8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)^M
        /home/vries/oacc/trunk/source-gcc/gcc/rtl-error.c:108^M
0x609301 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)^M
        /home/vries/oacc/trunk/source-gcc/gcc/rtl-error.c:118^M
0xcb52ad extract_constrain_insn(rtx_insn*)^M
        /home/vries/oacc/trunk/source-gcc/gcc/recog.c:2196^M
0xb99457 check_rtl^M
        /home/vries/oacc/trunk/source-gcc/gcc/lra.c:2173^M
...

[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Error: insn does not        |[11 Regression] Error: insn
                   |satisfy its constraints,    |does not satisfy its
                   |internal compiler error: in |constraints, internal
                   |extract_constrain_insn, at  |compiler error: in
                   |recog.c:2196                |extract_constrain_insn, at
                   |                            |recog.c:2196
   Last reconfirmed|                            |2020-10-22
   Target Milestone|---                         |11.0
             Status|UNCONFIRMED                 |NEW
             Target|                            |x86_64-*-* i?86-*-*
     Ever confirmed|0                           |1
          Component|libgomp                     |target

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.

[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |liuhongt at gcc dot gnu.org,
                   |                            |vmakarov at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r11-4203-g7026bb9504eb0f95e114f832cd6dd14302376861
We have:
(insn 87 4 5 2 (set (reg:DI 189)
        (reg:DI 2 cx [ fact ])) "simd-2.f90":13:0 74 {*movdi_internal}
     (expr_list:REG_DEAD (reg:DI 2 cx [ fact ])
        (nil)))
...
(insn 76 75 81 2 (set (reg:V8DF 153 [ vect_c_20.334 ])
        (plus:V8DF (vec_duplicate:V8DF (mem:DF (reg:DI 189) [6 *fact_18(D)+0 S8
A64]))
            (reg:V8DF 184 [ vect__17.333 ]))) "simd-2.f90":18:0 1569
{*addv8df3}
     (expr_list:REG_DEAD (reg:DI 189)
        (expr_list:REG_DEAD (reg:V8DF 184 [ vect__17.333 ])
            (nil))))
as the only insns that refer to pseudo 189, and for some reason IRA decides to
allocate that pseudo into xmm4 register which is not valid for memory
addresses.
So, something in the r11-4202 IRA changes doesn't work properly (and maybe
something in LRA too, because even if IRA decides to put it into such register,
which it e.g. could because 95% of uses would be in vector register contexts,
LRA should be able to fix it up, shouldn't it?

[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The IRA dump says:
  a2(r189,l0) costs: AREG:2000,2000 DREG:2000,2000 CREG:26000,-1000
BREG:2000,2000 SIREG:2000,2000 DIREG:2000,2000 AD_REGS:2000,2000 CLOBBERED_REGS
:2000,2000 Q_REGS:2000,2000 TLS_GOTBASE_REGS:2000,2000 GENERAL_REGS:2000,2000
SSE_FIRST_REG:12000,12000 NO_REX_SSE_REGS:12000,12000 SSE_REGS:12000,
12000 ALL_SSE_REGS:12000,12000 MMX_REGS:26000,26000 INT_SSE_REGS:26000,26000
ALL_REGS:424000,424000 MEM:12000,12000
so the INT_SSE_REGS cost of 26000 seems might higher than GENERAL_REGS cost.

[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196

[vmakarov at gcc dot gnu.org]

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

--- Comment #4 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #3)
> The IRA dump says:
>   a2(r189,l0) costs: AREG:2000,2000 DREG:2000,2000 CREG:26000,-1000
> BREG:2000,2000 SIREG:2000,2000 DIREG:2000,2000 AD_REGS:2000,2000
> CLOBBERED_REGS
> :2000,2000 Q_REGS:2000,2000 TLS_GOTBASE_REGS:2000,2000
> GENERAL_REGS:2000,2000 SSE_FIRST_REG:12000,12000 NO_REX_SSE_REGS:12000,12000
> SSE_REGS:12000,
> 12000 ALL_SSE_REGS:12000,12000 MMX_REGS:26000,26000 INT_SSE_REGS:26000,26000
> ALL_REGS:424000,424000 MEM:12000,12000
> so the INT_SSE_REGS cost of 26000 seems might higher than GENERAL_REGS cost.

It does not matter what class IRA gives the address reg. LRA should fix this
anyway.  For usual memory the correct address reg class is checked by
legitimate_address_p hook.

I guess in this case it is a special memory and its constraint does not check
address reg class at all.  I believe the bug should be fixed on
machine-dependent side of GCC (in constraints and predicates).

[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The operand in this case is the whole
(vec_duplicate:V8DF (mem:DF (reg...) [6 *fact_18(D)+0 S8 A64]))
which matches the
(define_special_memory_constraint "Br"
  "@internal bcst memory operand."
  (match_operand 0 "bcst_mem_operand"))
constraint where bcst_mem_operand is:
(define_predicate "bcst_mem_operand"
  (and (match_code "vec_duplicate")
       (and (match_test "TARGET_AVX512F")
            (ior (match_test "TARGET_AVX512VL")
                 (match_test "GET_MODE_SIZE (GET_MODE (op)) == 64")))
       (match_test "VALID_BCST_MODE_P (GET_MODE_INNER (GET_MODE (op)))")
       (match_test "memory_operand (XEXP (op, 0), GET_MODE (XEXP (op, 0)))")))
I think the extract_mem_from_operand function has been introduced for this in
LRA, but perhaps it is not used in all the places where it is needed.

[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196

[crazylht at gmail dot com]

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

Hongtao.liu <crazylht at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |crazylht at gmail dot com

--- Comment #6 from Hongtao.liu <crazylht at gmail dot com> ---


(In reply to Vladimir Makarov from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > The IRA dump says:
> >   a2(r189,l0) costs: AREG:2000,2000 DREG:2000,2000 CREG:26000,-1000
> > BREG:2000,2000 SIREG:2000,2000 DIREG:2000,2000 AD_REGS:2000,2000
> > CLOBBERED_REGS
> > :2000,2000 Q_REGS:2000,2000 TLS_GOTBASE_REGS:2000,2000
> > GENERAL_REGS:2000,2000 SSE_FIRST_REG:12000,12000 NO_REX_SSE_REGS:12000,12000
> > SSE_REGS:12000,
> > 12000 ALL_SSE_REGS:12000,12000 MMX_REGS:26000,26000 INT_SSE_REGS:26000,26000
> > ALL_REGS:424000,424000 MEM:12000,12000
> > so the INT_SSE_REGS cost of 26000 seems might higher than GENERAL_REGS cost.
> 
> It does not matter what class IRA gives the address reg. LRA should fix this
> anyway.  For usual memory the correct address reg class is checked by
> legitimate_address_p hook.
> 
> I guess in this case it is a special memory and its constraint does not
> check address reg class at all.  I believe the bug should be fixed on
> machine-dependent side of GCC (in constraints and predicates).

In 
(define_predicate "bcst_mem_operand"
  (and (match_code "vec_duplicate")
       (and (match_test "TARGET_AVX512F")
            (ior (match_test "TARGET_AVX512VL")
                 (match_test "GET_MODE_SIZE (GET_MODE (op)) == 64")))
       (match_test "VALID_BCST_MODE_P (GET_MODE_INNER (GET_MODE (op)))")
       (match_test "memory_operand (XEXP (op, 0), GET_MODE (XEXP (op, 0)))")))

Shouldn't memory_operand (XEXP (op, 0), GET_MODE (XEXP (op, 0))) imply
legitimate_address_p?

[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
memory_operand calls general_operand which for MEM does:
      /* Use the mem's mode, since it will be reloaded thus.  LRA can
         generate move insn with invalid addresses which is made valid
         and efficiently calculated by LRA through further numerous
         transformations.  */
      if (lra_in_progress
          || memory_address_addr_space_p (GET_MODE (op), y, MEM_ADDR_SPACE
(op)))
        return 1;
So, during LRA it accepts anything, and at the end of LRA it ICEs because it
isn't recognized.
So, I think LRA needs to know somewhere what is the address operand of the MEM
even inside of the bcst_mem_operand and know that it should fix it up.

[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196

[crazylht at gmail dot com]

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

--- Comment #8 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Jakub Jelinek from comment #7)
> memory_operand calls general_operand which for MEM does:
>       /* Use the mem's mode, since it will be reloaded thus.  LRA can
>          generate move insn with invalid addresses which is made valid
>          and efficiently calculated by LRA through further numerous
>          transformations.  */
>       if (lra_in_progress
>           || memory_address_addr_space_p (GET_MODE (op), y, MEM_ADDR_SPACE
> (op)))
>         return 1;
> So, during LRA it accepts anything, and at the end of LRA it ICEs because it
> isn't recognized.
> So, I think LRA needs to know somewhere what is the address operand of the
> MEM even inside of the bcst_mem_operand and know that it should fix it up.

Yes, and i saw at least two places needed to be adjusted.

First in process_address_1 (int nop, bool check_only_p,
---
3430   /* Do not attempt to decompose arbitrary addresses generated by combine
3431      for asm operands with loose constraints, e.g 'X'.  */
3432   else if (MEM_P (op)  ---------------------------------------> Here!!!
3433            && !(INSN_CODE (curr_insn) < 0
3434                 && get_constraint_type (cn) == CT_FIXED_FORM
3435                 && constraint_satisfied_p (op, cn)))
3436     decompose_mem_address (&ad, op);
3437   else if (GET_CODE (op) == SUBREG
3438            && MEM_P (SUBREG_REG (op)))
3439     decompose_mem_address (&ad, SUBREG_REG (op));
3440   else
3441     return false;
---

Then in valid_address_p which would be called in process_address_1
---
 398 /* Return true if the eliminated form of AD is a legitimate target
address.
 399    If OP is a MEM, AD is the address within OP, otherwise OP should be
 400    ignored.  CONSTRAINT is one constraint that the operand may need
 401    to meet.  */
 402 static bool
 403 valid_address_p (rtx op, struct address_info *ad,
 404                  enum constraint_num constraint)
 405 {
 406   address_eliminator eliminator (ad);
 407 
 408   /* Allow a memory OP if it matches CONSTRAINT, even if CONSTRAINT is
more
 409      forgiving than "m".  */
 410   if (MEM_P (op) -----------------------------------------------> Here.
 411       && (insn_extra_memory_constraint (constraint)
 412           || insn_extra_special_memory_constraint (constraint))
 413       && constraint_satisfied_p (op, constraint))
 414     return true;
 415 
 416   return valid_address_p (ad->mode, *ad->outer, ad->as);
 417 }
---

[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196

[vmakarov at gcc dot gnu.org]

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

--- Comment #9 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Hongtao.liu from comment #6)
> 
> 
> Shouldn't memory_operand (XEXP (op, 0), GET_MODE (XEXP (op, 0))) imply
> legitimate_address_p?

memory_operand does not imply legitimate_address_p.  When LRA processes regular
memory it calls legitimate_address_p.  But for special memory it did not do
this.  It is a responsibility of special constraint to check it.  That is why
it is called special (it might require more constraints on addressing or hard
registers can be used).  I guess you should check it in the constraint that
base and index registers are of the right class.

[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196

[crazylht at gmail dot com]

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

--- Comment #10 from Hongtao.liu <crazylht at gmail dot com> ---
Created attachment 49444
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49444&action=edit
Fix invalid address for special memory constraint

I'm testing this patch.

[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dcb314 at hotmail dot com

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
*** Bug 97606 has been marked as a duplicate of this bug. ***

[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196

[vries at gcc dot gnu.org]

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

--- Comment #12 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Hongtao.liu from comment #10)
> Created attachment 49444 [details]
> Fix invalid address for special memory constraint
> 
> I'm testing this patch.

Submitted: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557142.html

[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196

[crazylht at gmail dot com]

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

--- Comment #13 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Tom de Vries from comment #12)
> (In reply to Hongtao.liu from comment #10)
> > Created attachment 49444 [details]
> > Fix invalid address for special memory constraint
> > 
> > I'm testing this patch.
> 
> Submitted: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557142.html

Assume you are asking for when would this patch be submitted.(In reply to Tom
de Vries from comment #12)
> (In reply to Hongtao.liu from comment #10)
> > Created attachment 49444 [details]
> > Fix invalid address for special memory constraint
> > 
> > I'm testing this patch.
> 
> Submitted: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557142.html

Related discussion at
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557143.html

[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by hongtao Liu <liuhongt@gcc.gnu.org>:

https://gcc.gnu.org/g:db8b3e148d5cc5358cd48886e5334bd50d2d3317

commit r11-4703-gdb8b3e148d5cc5358cd48886e5334bd50d2d3317
Author: liuhongt <hongtao.liu@intel.com>
Date:   Mon Oct 26 20:45:23 2020 +0800

    Fix invalid address for special_memory_constraint.

    gcc/ChangeLog
            PR target/97532
            * lra-constraints.c (valid_address_p): Handle operand of
            special memory constraint.
            (process_address_1): Ditto.

[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196

[crazylht at gmail dot com]

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

--- Comment #15 from Hongtao.liu <crazylht at gmail dot com> ---
Fixed in GCC11.

[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
.