diff options
| author | Jakub Jelinek <jakub@redhat.com> | 2024-03-23 11:20:00 +0100 |
|---|---|---|
| committer | Jakub Jelinek <jakub@redhat.com> | 2024-03-23 11:20:00 +0100 |
| commit | 4a46a48ebc7b7b3976af49f6f8dabd65c6ddf64b (patch) | |
| tree | 1ecfee92ab09fe90c7f2eab958a92a52c9beb957 /gcc/fold-const.cc | |
| parent | f92cf8cbbe199bda70d0dd7893e8c8836777e2d0 (diff) | |
| download | gcc-4a46a48ebc7b7b3976af49f6f8dabd65c6ddf64b.zip gcc-4a46a48ebc7b7b3976af49f6f8dabd65c6ddf64b.tar.gz gcc-4a46a48ebc7b7b3976af49f6f8dabd65c6ddf64b.tar.bz2 | |
bitint: Fix bitfield loads in handle_cast [PR114433]
We ICE on the following testcase, because handle_cast was incorrectly
testing !m_first to see whether it should use m_data[m_bitfld_load + 1]
or fresh SSA_NAME for a PHI result.
Now, m_first is in the routine sometimes temporarily cleared in between
doing prepare_data_in_out and the !m_first check and only before returning
restored from the save_first copy.
Without this patch, we try to use the same SSA_NAME (_12 here) in 2
different PHI results which is obviously invalid IL and ICEs very quickly.
2024-03-23 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/114433
* gimple-lower-bitint.cc (bitint_large_huge::handle_cast): For
m_bitfld_load check save_first rather than m_first.
* gcc.dg/torture/bitint-68.c: New test.
Diffstat (limited to 'gcc/fold-const.cc')
0 files changed, 0 insertions, 0 deletions