* [Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
2020-10-22 16:12 [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
@ 2020-10-22 16:32 ` rguenth at gcc dot gnu.org
2020-10-22 17:16 ` jakub at gcc dot gnu.org
` (14 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-10-22 16:32 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
2020-10-22 16:12 [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
2020-10-22 16:32 ` [Bug target/97532] [11 Regression] " rguenth at gcc dot gnu.org
@ 2020-10-22 17:16 ` jakub at gcc dot gnu.org
2020-10-22 18:19 ` jakub at gcc dot gnu.org
` (13 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-10-22 17:16 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
2020-10-22 16:12 [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
2020-10-22 16:32 ` [Bug target/97532] [11 Regression] " rguenth at gcc dot gnu.org
2020-10-22 17:16 ` jakub at gcc dot gnu.org
@ 2020-10-22 18:19 ` jakub at gcc dot gnu.org
2020-10-22 18:48 ` vmakarov at gcc dot gnu.org
` (12 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-10-22 18:19 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
2020-10-22 16:12 [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
` (2 preceding siblings ...)
2020-10-22 18:19 ` jakub at gcc dot gnu.org
@ 2020-10-22 18:48 ` vmakarov at gcc dot gnu.org
2020-10-22 19:03 ` jakub at gcc dot gnu.org
` (11 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: vmakarov at gcc dot gnu.org @ 2020-10-22 18:48 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
2020-10-22 16:12 [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
` (3 preceding siblings ...)
2020-10-22 18:48 ` vmakarov at gcc dot gnu.org
@ 2020-10-22 19:03 ` jakub at gcc dot gnu.org
2020-10-23 5:49 ` crazylht at gmail dot com
` (10 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-10-22 19:03 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
2020-10-22 16:12 [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
` (4 preceding siblings ...)
2020-10-22 19:03 ` jakub at gcc dot gnu.org
@ 2020-10-23 5:49 ` crazylht at gmail dot com
2020-10-23 7:42 ` jakub at gcc dot gnu.org
` (9 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: crazylht at gmail dot com @ 2020-10-23 5:49 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
2020-10-22 16:12 [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
` (5 preceding siblings ...)
2020-10-23 5:49 ` crazylht at gmail dot com
@ 2020-10-23 7:42 ` jakub at gcc dot gnu.org
2020-10-23 8:11 ` crazylht at gmail dot com
` (8 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-10-23 7:42 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
2020-10-22 16:12 [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
` (6 preceding siblings ...)
2020-10-23 7:42 ` jakub at gcc dot gnu.org
@ 2020-10-23 8:11 ` crazylht at gmail dot com
2020-10-23 15:21 ` vmakarov at gcc dot gnu.org
` (7 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: crazylht at gmail dot com @ 2020-10-23 8:11 UTC (permalink / raw)
To: gcc-bugs
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 }
---
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
2020-10-22 16:12 [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
` (7 preceding siblings ...)
2020-10-23 8:11 ` crazylht at gmail dot com
@ 2020-10-23 15:21 ` vmakarov at gcc dot gnu.org
2020-10-27 6:05 ` crazylht at gmail dot com
` (6 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: vmakarov at gcc dot gnu.org @ 2020-10-23 15:21 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
2020-10-22 16:12 [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
` (8 preceding siblings ...)
2020-10-23 15:21 ` vmakarov at gcc dot gnu.org
@ 2020-10-27 6:05 ` crazylht at gmail dot com
2020-10-28 9:40 ` rguenth at gcc dot gnu.org
` (5 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: crazylht at gmail dot com @ 2020-10-27 6:05 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
2020-10-22 16:12 [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
` (9 preceding siblings ...)
2020-10-27 6:05 ` crazylht at gmail dot com
@ 2020-10-28 9:40 ` rguenth at gcc dot gnu.org
2020-10-29 12:36 ` vries at gcc dot gnu.org
` (4 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-10-28 9:40 UTC (permalink / raw)
To: gcc-bugs
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. ***
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
2020-10-22 16:12 [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
` (10 preceding siblings ...)
2020-10-28 9:40 ` rguenth at gcc dot gnu.org
@ 2020-10-29 12:36 ` vries at gcc dot gnu.org
2020-10-30 0:54 ` crazylht at gmail dot com
` (3 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: vries at gcc dot gnu.org @ 2020-10-29 12:36 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
2020-10-22 16:12 [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
` (11 preceding siblings ...)
2020-10-29 12:36 ` vries at gcc dot gnu.org
@ 2020-10-30 0:54 ` crazylht at gmail dot com
2020-11-04 5:07 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: crazylht at gmail dot com @ 2020-10-30 0:54 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
2020-10-22 16:12 [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
` (12 preceding siblings ...)
2020-10-30 0:54 ` crazylht at gmail dot com
@ 2020-11-04 5:07 ` cvs-commit at gcc dot gnu.org
2020-11-04 5:13 ` crazylht at gmail dot com
2020-11-18 15:45 ` jakub at gcc dot gnu.org
15 siblings, 0 replies; 17+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-11-04 5:07 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
2020-10-22 16:12 [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
` (13 preceding siblings ...)
2020-11-04 5:07 ` cvs-commit at gcc dot gnu.org
@ 2020-11-04 5:13 ` crazylht at gmail dot com
2020-11-18 15:45 ` jakub at gcc dot gnu.org
15 siblings, 0 replies; 17+ messages in thread
From: crazylht at gmail dot com @ 2020-11-04 5:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97532
--- Comment #15 from Hongtao.liu <crazylht at gmail dot com> ---
Fixed in GCC11.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
2020-10-22 16:12 [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
` (14 preceding siblings ...)
2020-11-04 5:13 ` crazylht at gmail dot com
@ 2020-11-18 15:45 ` jakub at gcc dot gnu.org
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-11-18 15:45 UTC (permalink / raw)
To: gcc-bugs
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> ---
.
^ permalink raw reply [flat|nested] 17+ messages in thread