aboutsummaryrefslogtreecommitdiff
path: root/libgcc
diff options
context:
space:
mode:
authorJuzhe-Zhong <juzhe.zhong@rivai.ai>2023-08-11 21:55:42 +0800
committerPan Li <pan2.li@intel.com>2023-08-12 05:50:35 +0800
commit5bfb5e772f6cf121563f08d27d2c652ea469bbfb (patch)
tree65fc4c1daebc8255890105bcadb833c3e32018bc /libgcc
parent2b1b804de2687c9f705cc3625e467dfa18723a45 (diff)
downloadgcc-5bfb5e772f6cf121563f08d27d2c652ea469bbfb.zip
gcc-5bfb5e772f6cf121563f08d27d2c652ea469bbfb.tar.gz
gcc-5bfb5e772f6cf121563f08d27d2c652ea469bbfb.tar.bz2
VECT: Fix ICE on MASK_LEN_{LOAD, STORE} when no LEN recorded[PR110989]
This ICE is caused because of this situation: mask__49.21_99 = vect__17.19_96 == { 0.0, ... }; ... vect__6.24_107 = .MASK_LEN_LOAD (vectp.22_105, 32B, mask__49.21_99, POLY_INT_CST [2, 2], 0); The MASK_LEN_LOAD is using real MASK which is produced by the EQ comparison wheras the LEN is the dummy LEN which is the vectorization factor. In this situation, we didn't enter 'vect_record_loop_len' since there is no LEN loop control. Then 'LOOP_VINFO_RGROUP_IV_TYPE' is not suitable type for 'build_int_cst' used for producing LEN argument for 'MASK_LEN_LOAD', so use sizetype instead which is perfectly matching RVV length requirement. gcc/ChangeLog: PR middle-end/110989 * tree-vect-stmts.cc (vectorizable_store): Replace iv_type with sizetype. (vectorizable_load): Ditto. gcc/testsuite/ChangeLog: PR middle-end/110989 * gcc.target/riscv/rvv/autovec/pr110989.c: New test.
Diffstat (limited to 'libgcc')
0 files changed, 0 insertions, 0 deletions