aboutsummaryrefslogtreecommitdiff
path: root/gcc/fortran/symbol.c
diff options
context:
space:
mode:
authorKewen Lin <linkw@linux.ibm.com>2020-06-27 21:17:04 -0500
committerKewen Lin <linkw@linux.ibm.com>2020-06-27 21:17:04 -0500
commitef8d1da1b585e0de4b2a0e7721fc13974c00134e (patch)
treea682c33f578ef9c95ef7244d398ad043bbe859ea /gcc/fortran/symbol.c
parent5771314d189cc38fa282c7f092ebaa9f1ec06db6 (diff)
downloadgcc-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