https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81596
Bug ID: 81596
Summary: backwards threader misses simple copy within the same
BB
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: aldyh at gcc dot gnu.org
Target Milestone: ---
For the following simple testcase, the SSA backwards threader misses that xcopy
is a copy of a constant, because the definitions for both xcopy and x all occur
in the same BB, and the threader incorrectly thinks it will infinitely recurse.
void com (void);
void
foo()
{
int x = 25;
int xcopy = x;
if (xcopy == 25)
com();
}
./cc1 test.c -fdump-tree-all-details-alias -quiet -I/tmp -O2 -fno-tree-vrp
-fno-tree-ccp -fno-early-inlining -fno-forward-propagate -fno-tree-forwprop
As can be seen in the early threader dump (*.ethread), the compare is still
there, even though we can easily see it's a constant. This happens because
fsm_find_control_statement_thread_paths() will mark the BB containing xcopy as
seen, and then recurse into
handle_assignment/fsm_find_control_statement_thread_paths again to find the
definition for xcopy. Since the definition of xcopy also occurs in the same
basic block, and we've marked the BB as seen, we bail with no further
processing:
/* Avoid infinite recursion. */
if (visited_bbs->add (var_bb))
return;
This is obviously a highly contrived test whose options disable a lot of the
optimizations that would've caused the problem to go away. As such, feel free
to mark as WONTFIX if this is something that will never happen in real life.
