On Wed, 15 Mar 2023, Jakub Jelinek wrote: > On Wed, Mar 15, 2023 at 10:48:32AM +0000, Richard Biener wrote: > > use_after_inval_p uses stmt UIDs to speed up repeated dominance > > checks within a basic-block but it fails to assign UIDs to PHIs > > which means compares with PHIs in the same block get a random > > result. > > > > The following factors renumber_gimple_stmt_uids to expose a new > > renumber_gimple_stmt_uids_in_block we can share. > > > > This XFAILs the conditional loop case in gcc.dg/Wuse-after-free-2.c > > > > Bootstrap and regtest running on x86_64-unknown-linux-gnu. This > > makes 2/2 a net positive on the testsuite (the early waccess > > would not run into this bug) > > > > OK if testing succeeds? (we could also special-case PHIs somehow > > and assert we never get to compare two PHIs here) > > > > * tree-dfa.h (renumber_gimple_stmt_uids_in_block): New. > > * tree-dfa.cc (renumber_gimple_stmt_uids_in_block): Split > > out from ... > > (renumber_gimple_stmt_uids): ... here and > > (renumber_gimple_stmt_uids_in_blocks): ... here. > > * gimple-ssa-warn-access.cc (pass_waccess::use_after_inval_p): > > Use renumber_gimple_stmt_uids_in_block to also assign UIDs > > to PHIs. > > > > * gcc.dg/Wuse-after-free-2.c: XFAIL conditional loop case. > > LGTM.
Turns out we rely very much on processing PHIs for following pointers (we also happily look at earlier pointer adjustments). So while the comparison done to PHIs in the above function is bogus and we should possibly fix it it regresses things unless we process PHIs unconditionally. I'm going to test an adjusted patch. Richard.
