diff options
author | Kewen Lin <linkw@linux.ibm.com> | 2020-06-27 21:17:04 -0500 |
---|---|---|
committer | Kewen Lin <linkw@linux.ibm.com> | 2020-06-27 21:17:04 -0500 |
commit | ef8d1da1b585e0de4b2a0e7721fc13974c00134e (patch) | |
tree | a682c33f578ef9c95ef7244d398ad043bbe859ea /gcc/fortran/symbol.c | |
parent | 5771314d189cc38fa282c7f092ebaa9f1ec06db6 (diff) | |
download | gcc-ef8d1da1b585e0de4b2a0e7721fc13974c00134e.zip gcc-ef8d1da1b585e0de4b2a0e7721fc13974c00134e.tar.gz gcc-ef8d1da1b585e0de4b2a0e7721fc13974c00134e.tar.bz2 |
IFN: Fix mask_{load,store} optab support macros
When I am working on IFNs for vector with length, I noticed that the
current optab support query for mask_load/mask_store looks unexpected.
The mask_load/mask_store requires two modes for convert_optab query,
but the macros direct_mask_{load,store}_optab_supported_p uses
direct_optab_supported_p which asserts type pair should have the same mode.
I'm not sure whether we have some special reason here or just a typo,
since everything goes well now, mask_{load,store} optab check is mainly
handled by can_vec_mask_load_store_p.
But if we have some codes as below (eg: one checking for all IFNs finally)
tree_pair types = direct_internal_fn_types (ifn, call);
if(direct_internal_fn_supported_p (ifn, types, OPTIMIZE_FOR_SPEED) ...
It will cause ICE.
gcc/ChangeLog:
* internal-fn.c (direct_mask_load_optab_supported_p): Use
convert_optab_supported_p instead of direct_optab_supported_p.
(direct_mask_store_optab_supported_p): Likewise.
Diffstat (limited to 'gcc/fortran/symbol.c')
0 files changed, 0 insertions, 0 deletions