[Bug target/91604] [10 Regression] ICE in extract_insn at recog.c:2310 since r272323
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91604 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug target/91604] [10 Regression] ICE in extract_insn at recog.c:2310 since r272323
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91604 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Tue Sep 3 16:46:06 2019 New Revision: 275344 URL: https://gcc.gnu.org/viewcvs?rev=275344&root=gcc&view=rev Log: PR target/91604 * config/i386/i386-expand.c (split_double_mode): If there is more than one MEM operand and they are rtx_equal_p, reuse lo_half/hi_half from already split matching MEM operand instead of calling adjust_address again. * gcc.target/i386/pr91604.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr91604.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-expand.c trunk/gcc/testsuite/ChangeLog
[Bug target/91604] [10 Regression] ICE in extract_insn at recog.c:2310 since r272323
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91604 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 46799 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46799&action=edit gcc10-pr91604.patch I can reproduce if I pass -msse2, otherwise I couldn't. Anyway, the problem with this set of command line options is that when adjust_address_1 calls change_address_1, it will do: 417 /* By passing constant addresses through registers 418 we get a chance to cse them. */ 419 if (! cse_not_expected && CONSTANT_P (x) && CONSTANT_ADDRESS_P (x)) 420x = force_reg (address_mode, x); As split_double_mode does that separately for each MEM, we end up with different addresses between what is supposed to be a matching MEM, only some later CSE would optimize it back again, but we run into the recog failure before that. The attached patch fixes it by special casing it in split_double_mode, if we have a rtx_equal_p MEM operand, reuse the previously split operand rather than create it again. Assumes at most one matching MEM, which is I think generally the case in the backend.
[Bug target/91604] [10 Regression] ICE in extract_insn at recog.c:2310 since r272323
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91604
--- Comment #3 from Uroš Bizjak ---
(In reply to Martin Liška from comment #2)
> (In reply to Uroš Bizjak from comment #1)
> > Hm, I can't trigger the failure with gcc version 10.0.0 20190829
> > (experimental).
>
> https://godbolt.org/z/T068Mt
Sorry, I can't confirm. The pattern *one_cmpldi2_doubleword is correctly
protected by ix86_unary_operator_ok:
(define_insn_and_split "*one_cmpldi2_doubleword"
[(set (match_operand:DI 0 "nonimmediate_operand")
(not:DI (match_operand:DI 1 "nonimmediate_operand")))]
"!TARGET_64BIT && TARGET_STV && TARGET_SSE2
&& ix86_unary_operator_ok (NOT, DImode, operands)
&& can_create_pseudo_p ()"
"#"
"&& 1"
[(set (match_dup 0)
(not:SI (match_dup 1)))
(set (match_dup 2)
(not:SI (match_dup 3)))]
"split_double_mode (DImode, &operands[0], 2, &operands[0], &operands[2]);")
which checks exactly for the operand mismatch that ICEs this test:
/* Return TRUE or FALSE depending on whether the unary operator meets the
appropriate constraints. */
bool
ix86_unary_operator_ok (enum rtx_code,
machine_mode,
rtx operands[2])
{
/* If one of operands is memory, source and destination must match. */
if ((MEM_P (operands[0])
|| MEM_P (operands[1]))
&& ! rtx_equal_p (operands[0], operands[1]))
return false;
return true;
}
split1 dump shows:
(insn 5 2 6 2 (set (mem/c:SI (symbol_ref:SI ("v") [flags 0x2] ) [1 v+0 S4 A64])
(not:SI (mem/c:SI (symbol_ref:SI ("v") [flags 0x2] ) [1 v+0 S4 A64]))) "pr91604.c":2:17 504 {*one_cmplsi2_1}
(nil))
(insn 6 5 9 2 (set (mem/c:SI (const:SI (plus:SI (symbol_ref:SI ("v") [flags
0x2] )
(const_int 4 [0x4]))) [1 v+4 S4 A32])
(not:SI (mem/c:SI (const:SI (plus:SI (symbol_ref:SI ("v") [flags 0x2]
)
(const_int 4 [0x4]))) [1 v+4 S4 A32])))
"pr91604.c":2:17 504 {*one_cmplsi2_1}
(nil))
There is no way that mismatched memory arguments enter *one_cmpldi2_doubleword,
so perhaps adjust_address in split_double_mode is doing some "optimization".
[Bug target/91604] [10 Regression] ICE in extract_insn at recog.c:2310 since r272323
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91604 --- Comment #2 from Martin Liška --- (In reply to Uroš Bizjak from comment #1) > Hm, I can't trigger the failure with gcc version 10.0.0 20190829 > (experimental). https://godbolt.org/z/T068Mt
[Bug target/91604] [10 Regression] ICE in extract_insn at recog.c:2310 since r272323
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91604 --- Comment #1 from Uroš Bizjak --- Hm, I can't trigger the failure with gcc version 10.0.0 20190829 (experimental).
[Bug target/91604] [10 Regression] ICE in extract_insn at recog.c:2310 since r272323
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91604 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-08-30 Known to work||9.2.0 Host||x86_64-linux-gnu Target Milestone|--- |10.0 Ever confirmed|0 |1 Known to fail||10.0
