https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126228
Bug ID: 126228
Summary: ranger: cannot look back through a conditional
Product: gcc
Version: 17.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: aldyh at gcc dot gnu.org
CC: amacleod at redhat dot com
Blocks: 126010
Target Milestone: ---
Created attachment 65020
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=65020&action=edit
testcase
This one is possibly a red herring, as it DOM had copy propagated desc_272 into
desc_269, so this may be a case of changing IL. But I’m including it here for
completeness since this completes the class of bugs I’ve seen on a cursory look
through all the .ii files in a stage1 bootstrap.
After this I’ll do a similar pass through some .ii files containing float
operations. This should give us a good idea of what the ranger and friends may
be missing.
Reproduce with -O2 -fdump-tree-dom-all.
The threading candidate is BB164->BB167 and we are trying to fold:
if (desc_269 != 0B)
BB163, the only predecessor of BB164, is:
<bb 163> [local count: 1804255]:
_240 = desc_269 != 0B;
_241 = _32 != 5;
_242 = _240 & _241;
if (_242 != 0)
goto <bb 164>; [33.00%]
else
goto <bb 165>; [67.00%]
So on entry to the path (the 163->164 edge) we know _242 is true, which makes
_240 true, which makes desc_269 != 0B true, and DOM folds the conditional to
true.
Interestingly, the root ranger sees _240 on 163->164 as [1,1], yet it has
desc_269 as VARYING on that same edge.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126010
[Bug 126010] [meta-bug] Remove DOM
