aboutsummaryrefslogtreecommitdiff
path: root/gcc/tree-vect-loop-manip.cc
diff options
context:
space:
mode:
authorJakub Jelinek <jakub@redhat.com>2023-12-22 12:27:05 +0100
committerJakub Jelinek <jakub@redhat.com>2023-12-22 12:27:05 +0100
commitd3defa435e9d04d6ab6585ac184989941c7ad51e (patch)
treeca165ad683f884757877abadd10e07ad52bb135c /gcc/tree-vect-loop-manip.cc
parent05d353b79441a708f43768383e2358c878ab727b (diff)
downloadgcc-d3defa435e9d04d6ab6585ac184989941c7ad51e.zip
gcc-d3defa435e9d04d6ab6585ac184989941c7ad51e.tar.gz
gcc-d3defa435e9d04d6ab6585ac184989941c7ad51e.tar.bz2
lower-bitint: Fix handle_cast ICE [PR113102]
My recent change to use m_data[save_data_cnt] instead of m_data[save_data_cnt + 1] when inside of a loop (m_bb is non-NULL) broke the following testcase. When we create a PHI node on the loop using prepare_data_in_out, both m_data[save_data_cnt{, + 1}] are computed and the fix was right, but there are also cases when we in a loop (m_bb non-NULL) emit a nested cast with too few limbs and then just use constant indexes for all accesses - in that case only m_data[save_data_cnt + 1] is initialized and m_data[save_data_cnt] is NULL. In those cases, we want to use the former. 2023-12-22 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/113102 * gimple-lower-bitint.cc (bitint_large_huge::handle_cast): Only use m_data[save_data_cnt] if it is non-NULL. * gcc.dg/bitint-58.c: New test.
Diffstat (limited to 'gcc/tree-vect-loop-manip.cc')
0 files changed, 0 insertions, 0 deletions