https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
--- Comment #21 from Andrew Macleod <amacleod at redhat dot com> ---
In reply to Jakub Jelinek from comment #19)
> Note, we call in that function get_range_pos_neg first on _54
> on the _55 = (sizetype) _54; statement (same block 11), that is the first
> ranger query during expansion of that function and already there it returns
> incorrect [7, 7].
>
> There are 3 BB_RTL basic blocks in the IL, one created by
> init_block = create_basic_block (NEXT_INSN (get_insns ()),
> get_last_insn (),
> ENTRY_BLOCK_PTR_FOR_FN (cfun));
> which adds a new BB on the edge from ENTRY to its original successor, and
> then two
> BB_RTL bbs created by
> new_bb = create_basic_block (NEXT_INSN (last), get_last_insn (), bb);
> in expand_gimple_cond for the case where neither successor of GIMPLE_COND
> ending bb is the next bb.
Looking at the output I see:
ivtmp.24_49 : BACK visiting block 6 for ivtmp.24_49
4->6 pushing undefined pred block.
5->6 pushing undefined pred block.
BACK visiting block 5 for ivtmp.24_49
4->5 has cache, [irange] UNDEFINED, BACK visiting block 4 for ivtmp.24_49
2->4 pushing undefined pred block.
3->4 pushing undefined pred block.
BACK visiting block 3 for ivtmp.24_49
2->3 has cache, [irange] UNDEFINED, BACK visiting block 2 for ivtmp.24_49
13->2 pushing undefined pred block.
BACK visiting block 13 for ivtmp.24_49
0->13 entry: bail.
DONE visiting blocks for ivtmp.24_49
Propagation update done.
TRUE : (2040) range_on_entry (ivtmp.24_49) [irange]
UNDEFINED
TRUE : (2039) range_on_exit (ivtmp.24_49) [irange] UNDEFINED
TRUE : (2038) range_on_edge (ivtmp.24_49) [irange] UNDEFINED
So the cache is trying to fill itself, and it is not finding the defintion
block for ivtmp.24_49.
in the .optimized file, the PHI node was:
# ivtmp.24_52 = PHI <ivtmp.24_49(10), 1(6)>
So looking for ivtmp.24_49 would go to block 10, and find the definition.
In the current expand listing, the PHI node being folded now looks like:
ivtmp.24_52 = PHI <ivtmp.24_49(6), 1(15)>
THis I think is the root of the problem Its goig to go to block 6 and start
looking for a defintion of ivtmp.24_49 because the PHI naode says thats where
the value is coming from.
so the cache is following the CFG as it sees it whicb is:
2
/ |
3 |
\ |
4
/ |
5 |
\ |
6
so its looking for the def of ivtmp.24_49 (which presumably still is in BB 10)
and not finding it. From the cache's point of view, it considers that a USED
before DEFINED case, and so it leaves the value as UNDEFINED.. and bad things
happen after that.
First question would be why has the PHI node been changed to an incom,ing edge
of BB6? it needs to lead to the defintion of ivtmp.24_49.
I notice the constant in the second argument also has a new edge from BB 15.
