[Bug target/93637] [9 Regression] ICE: Segmentation fault (in force_operand)

2020-02-14 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93637

--- Comment #10 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:231b10fe9f870a8a8a162e95416a6bc6df023839

commit r8-10017-g231b10fe9f870a8a8a162e95416a6bc6df023839
Author: Jakub Jelinek 
Date:   Fri Feb 14 15:48:42 2020 +0100

i386: Fix -mavx -mno-mavx2 ICE with VEC_COND_EXPR [PR93637]

As mentioned in the PR, for -mavx -mno-avx2 the backend does support
vcondv4div4df and vcondv8siv8sf optabs (while generally 32-byte vectors
aren't much supported in that case, it is performed using
vandps/vandnps/vorps).  The problem is that after the last generic vector
lowering (where the VEC_COND_EXPR still compares two V4DF vectors and
has two V4DI last operands and V4DI result and so is considered ok) fre4
folds the condition into constant, at which point the middle-end during
expansion will try vcond_mask_optab and fall back to trying to expand it
as the constant vector < 0 vcondv4div4di, but neither of them is supported
for -mavx -mno-avx2 and thus we ICE.

So, the options I see is either what the following patch does, also support
vcond_mask_v4div4di and vcond_mask_v4siv4si already for TARGET_AVX, or
require for vcondv4div4df and vcondv8siv8sf TARGET_AVX2 rather than current
TARGET_AVX.

2020-02-10  Jakub Jelinek  

PR target/93637
* config/i386/sse.md (VI_256_AVX2): New mode iterator.
(vcond_mask_): Use it instead of VI_256.
Change condition from TARGET_AVX2 to TARGET_AVX.

* gcc.target/i386/avx-pr93637.c: New test.

[Bug target/93637] [9 Regression] ICE: Segmentation fault (in force_operand)

2020-02-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93637

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Jakub Jelinek  ---
Fixed for 9.3+.

[Bug target/93637] [9 Regression] ICE: Segmentation fault (in force_operand)

2020-02-13 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93637

--- Comment #8 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

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

commit r9-8223-gb7cbce7a174292adc7c9d6db81bba6922a591d69
Author: Jakub Jelinek 
Date:   Mon Feb 10 22:44:40 2020 +0100

i386: Fix -mavx -mno-mavx2 ICE with VEC_COND_EXPR [PR93637]

As mentioned in the PR, for -mavx -mno-avx2 the backend does support
vcondv4div4df and vcondv8siv8sf optabs (while generally 32-byte vectors
aren't much supported in that case, it is performed using
vandps/vandnps/vorps).  The problem is that after the last generic vector
lowering (where the VEC_COND_EXPR still compares two V4DF vectors and
has two V4DI last operands and V4DI result and so is considered ok) fre4
folds the condition into constant, at which point the middle-end during
expansion will try vcond_mask_optab and fall back to trying to expand it
as the constant vector < 0 vcondv4div4di, but neither of them is supported
for -mavx -mno-avx2 and thus we ICE.

So, the options I see is either what the following patch does, also support
vcond_mask_v4div4di and vcond_mask_v4siv4si already for TARGET_AVX, or
require for vcondv4div4df and vcondv8siv8sf TARGET_AVX2 rather than current
TARGET_AVX.

2020-02-10  Jakub Jelinek  

PR target/93637
* config/i386/sse.md (VI_256_AVX2): New mode iterator.
(vcond_mask_): Use it instead of VI_256.
Change condition from TARGET_AVX2 to TARGET_AVX.

* gcc.target/i386/avx-pr93637.c: New test.

[Bug target/93637] [9 Regression] ICE: Segmentation fault (in force_operand)

2020-02-10 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93637

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10 Regression] ICE:  |[9 Regression] ICE:
   |Segmentation fault (in  |Segmentation fault (in
   |force_operand)  |force_operand)

--- Comment #7 from Jakub Jelinek  ---
Fixed on the trunk so far.