https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111458
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aldyh at gcc dot gnu.org,
| |law at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
Last reconfirmed| |2023-09-19
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
The issue is that the loop structure is broken and thus asking for
determine_bb_domination_status and then
1594 nblocks = dfs_enumerate_from (loop->latch, 1,
dbds_continue_enumeration_p,
1595 bblocks, loop->num_nodes, bb);
doesn't work. We are likely threading if (1 != 0) branches in weird ways.
The problem likely gone away by doing threading in a separate pass in GCC 12.
Calling determine_bb_domination_status after we have done any transforms
definitely looks dangerous - this should be done _before_ any CFG changes.
This issue is still latent in the forward threader. The backward threader
calls this function from back_threader_profitability::profitable_path_p,
so before doing any CFG changes. In GCC 12 and later the remaining forward
threader instances are all from DOM(?).
Reduced testcase for the GCC 11 branch:
func_1() {
for (;;)
if (func_2())
safe_lshift_func_uint16_t_u_u();
}
func_2(p_3, p_4) {
char l_870;
p_4 = -2;
for (; p_4; p_4 = p_4 + 1) {
int l_888_0 = 5;
l_870 = 0;
for (; l_870 <= 0; l_870 += 1) {
p_3 = 0;
for (; p_3 >= 0; p_3 -= 1)
if (l_888_0)
break;
if (l_888_0)
break;
l_888_0 &= 0;
}
}
return p_3;
}
