diff options
author | Jakub Jelinek <jakub@redhat.com> | 2023-12-22 12:27:05 +0100 |
---|---|---|
committer | Jakub Jelinek <jakub@redhat.com> | 2023-12-22 12:27:05 +0100 |
commit | d3defa435e9d04d6ab6585ac184989941c7ad51e (patch) | |
tree | ca165ad683f884757877abadd10e07ad52bb135c /gcc/tree-vect-loop-manip.cc | |
parent | 05d353b79441a708f43768383e2358c878ab727b (diff) | |
download | gcc-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