https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101018
--- Comment #9 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Tejas Belagod <bela...@gcc.gnu.org>: https://gcc.gnu.org/g:001fb23ae46ba4bd1b5e43f756fa89e6fb94ce18 commit r15-9268-g001fb23ae46ba4bd1b5e43f756fa89e6fb94ce18 Author: Richard Sandiford <richard.sandif...@arm.com> Date: Fri May 12 10:33:25 2023 +0100 gomp: Various fixes for SVE types [PR101018] Various parts of the omp code checked whether the size of a decl was an INTEGER_CST in order to determine whether the decl was variable-sized or not. If it was variable-sized, it was expected to have a DECL_VALUE_EXPR replacement, as for VLAs. This patch uses poly_int_tree_p instead, so that variable-length SVE vectors are treated like constant-length vectors. This means that some structures become poly_int-sized, with some fields at poly_int offsets, but we already have code to handle that. An alternative would have been to handle the data via indirection instead. However, that's likely to be more complicated, and it would contradict is_variable_sized, which already uses a check for TREE_CONSTANT rather than INTEGER_CST. gimple_add_tmp_var should probably not add a safelen of 1 for SVE vectors, but that's really a separate thing and might be hard to test. Co-authored-by: Tejas Belagod <tejas.bela...@arm.com> gcc/ PR middle-end/101018 * poly-int.h (can_and_p): New function. * fold-const.cc (poly_int_binop): Use it to optimize BIT_AND_EXPRs involving POLY_INT_CSTs. * gimplify.cc (omp_notice_variable): Use poly_int_tree_p instead of INTEGER_CST when checking for constant-sized omp data. (gimplify_adjust_omp_clauses_1): Likewise. (gimplify_adjust_omp_clauses): Likewise. * omp-low.cc (scan_sharing_clauses): Likewise.
