https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112668
--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:9a96a9e45b421436ca93efadba0f1901f12fb6c0 commit r14-5815-g9a96a9e45b421436ca93efadba0f1901f12fb6c0 Author: Jakub Jelinek <ja...@redhat.com> Date: Fri Nov 24 08:54:40 2023 +0100 lower-bitint: Fix up -fnon-call-exceptions bit-field load lowering [PR112668] As the following testcase shows, there are some bugs in the -fnon-call-exceptions bit-field load lowering. In particular, there is a case where we want to emit a load early in the initialization (before m_init_gsi) and because that load might throw exception, need to split block after the load so that it has an EH edge. Now, across this splitting, we have m_init_gsi, save_gsi (something we put back into m_gsi afterwards) statement iterators and m_preheader_bb which is used to determine the pre-header edge of a loop (if any). As the testcase shows, both of these statement iterators and m_preheader_bb as well need adjustments if the block was split. If the stmt iterators refer to a statement, they need to be updated so that if the statement is in the bb after the split gsi_bb and gsi_seq is updated, otherwise they ought to be the start of the new (second) bb. Similarly, m_preheader_bb should be updated to the second bb if it was the first before. Other spots where we insert something before m_init_gsi don't split blocks in there and are fine. The m_gsi iterator is normal iterator to insert statements before it, so gsi_end_p means insert statements at the end of basic block. m_init_gsi is on the other side an iterator after which statements should be inserted (so gsi_end_p means insert statements at the start of basic block after labels), but the whole pass is written for insertion of statements before iterators, so when in 3 spots it wants to insert something after m_init_gsi, it saves current iterator to save_gsi and sets m_gsi to gsi_after_labels if m_init_gsi was gsi_end_p, or to the next statement. But it actually wasn't updating m_init_gsi back when switching to normal iterator, this patch changes that such that further statements after m_init_gsi will appear after the set of statements inserted before m_init_gsi. Finally, the pass had a couple of places where it wanted to create a gsi_end_p iterator for a particular basic block, instead of doing m_gsi = gsi_last_bb (bb); if (!gsi_end_p (m_gsi)) gsi_next (&m_gsi); the pass now uses new m_gsi = gsi_end_bb (bb) function. 2023-11-24 Jakub Jelinek <ja...@redhat.com> PR middle-end/112668 * gimple-iterator.h (gsi_end, gsi_end_bb): New inline functions. * gimple-lower-bitint.cc (bitint_large_huge::handle_cast): After temporarily adding statements after m_init_gsi, update m_init_gsi such that later additions after it will be after the added statements. (bitint_large_huge::handle_load): Likewise. When splitting gsi_bb (m_init_gsi) basic block, update m_preheader_bb if needed and update saved m_gsi as well if needed. (bitint_large_huge::lower_mergeable_stmt, bitint_large_huge::lower_comparison_stmt, bitint_large_huge::lower_mul_overflow, bitint_large_huge::lower_bit_query): Use gsi_end_bb. * gcc.dg/bitint-40.c: New test.
