[Bug target/90187] [8/9 Regression] ICE in extract_insn, at recog.c:2304 x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90187 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Wed Apr 24 09:27:14 2019 New Revision: 270537 URL: https://gcc.gnu.org/viewcvs?rev=270537=gcc=rev Log: PR target/90187 * config/i386/i386.c (ix86_expand_sse_fp_minmax): Force if_true into a register if both if_true and if_false are MEMs. * g++.target/i386/pr90187.C: New test. Added: trunk/gcc/testsuite/g++.target/i386/pr90187.C Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug target/90187] [8/9 Regression] ICE in extract_insn, at recog.c:2304 x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90187
--- Comment #7 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #6)
> Or would you prefer:
> --- gcc/config/i386/i386.c.jj 2019-04-16 10:40:15.077091789 +0200
> +++ gcc/config/i386/i386.c2019-04-23 11:55:59.397227347 +0200
> @@ -23712,7 +23712,10 @@ ix86_expand_sse_fp_minmax (rtx dest, enu
>else
> {
>code = is_min ? SMIN : SMAX;
> - tmp = gen_rtx_fmt_ee (code, mode, if_true, if_false);
> + rtx operands[3] = { dest, if_true, if_false };
> + ix86_fixup_binary_operands_no_copy (code, mode, operands);
> + tmp = gen_rtx_fmt_ee (code, mode, operands[1], operands[2]);
> + dest = operands[0];
> }
>
>emit_insn (gen_rtx_SET (dest, tmp));
> instead? I think a switch on mode to handle all the possible modes in there
> and assign the different gen_{smin,smax}* in those cases would be too large.
No, the proposed patch that forces if_true operand to a register should be
enough. It doesn't make much difference calling ix86_fixup_binary_operands_*
without memory output operand.
[Bug target/90187] [8/9 Regression] ICE in extract_insn, at recog.c:2304 x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90187
--- Comment #6 from Jakub Jelinek ---
Or would you prefer:
--- gcc/config/i386/i386.c.jj 2019-04-16 10:40:15.077091789 +0200
+++ gcc/config/i386/i386.c 2019-04-23 11:55:59.397227347 +0200
@@ -23712,7 +23712,10 @@ ix86_expand_sse_fp_minmax (rtx dest, enu
else
{
code = is_min ? SMIN : SMAX;
- tmp = gen_rtx_fmt_ee (code, mode, if_true, if_false);
+ rtx operands[3] = { dest, if_true, if_false };
+ ix86_fixup_binary_operands_no_copy (code, mode, operands);
+ tmp = gen_rtx_fmt_ee (code, mode, operands[1], operands[2]);
+ dest = operands[0];
}
emit_insn (gen_rtx_SET (dest, tmp));
instead? I think a switch on mode to handle all the possible modes in there
and assign the different gen_{smin,smax}* in those cases would be too large.
[Bug target/90187] [8/9 Regression] ICE in extract_insn, at recog.c:2304 x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90187 --- Comment #5 from Jakub Jelinek --- Created attachment 46228 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46228=edit gcc9-pr90187.patch Untested fix.
[Bug target/90187] [8/9 Regression] ICE in extract_insn, at recog.c:2304 x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90187 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 --- That is not what I see. I see that vcondv2dfv2df is being expanded, and that one has general_operand and vector_operand predicates which do allow MEM. That calls ix86_expand_sse_fp_minmax which doesn't ensure both operands aren't MEM.
[Bug target/90187] [8/9 Regression] ICE in extract_insn, at recog.c:2304 x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90187
--- Comment #3 from Uroš Bizjak ---
It looks like middle-end is bypassing sminv2df3 expander and constructs RTX by
hand. This should not be done, since the expander decides whether IEEE or
non-IEEE variant should be used.
Please note that there is also an issue with {smax,smin}{sf,df}3, where
&& !(MEM_P (operands[1]) && MEM_P (operands[2]))
is (intentionally?) missing, and we depend on RA to fix invalid RTX.
[Bug target/90187] [8/9 Regression] ICE in extract_insn, at recog.c:2304 x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90187
--- Comment #2 from Jakub Jelinek ---
Simplified testcase:
double a[64];
double *foo (void);
void
bar (int x, const double *y)
{
int i;
for (i = 0; i < x; i++)
if (y[i] < a[i])
a[i] = y[i];
}
[Bug target/90187] [8/9 Regression] ICE in extract_insn, at recog.c:2304 x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90187 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-23 CC||jakub at gcc dot gnu.org Target Milestone|--- |8.4 Summary|ICE in extract_insn, at |[8/9 Regression] ICE in |recog.c:2304 x86_64 |extract_insn, at ||recog.c:2304 x86_64 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Doesn't reproduce on the trunk starting with r265489, likely latent afterwards. Started with r253975, likely latent before. I'll have a look.
