With my local patches to remove jump threading from VRP I was seeing a fairly obvious jump threading path left in the CFG after DOM. This missed jump thread ultimately caused a false positive uninitialized warning.
Interestingly enough when I looked at the dumps it appeared DOM was finding the appropriate threads, the threads weren't being cancelled and we weren't doing any undesirable duplications for joiners. What was happening is we had these two jump threading paths A: (190, 192) (192, 194) B: (192, 194) (194, 202) These are simple jump threading paths. No joiners or empty block skipping. The key here is that the target edge of path A is the starting edge of path B and that path A starts at a block with a smaller index. There's a variety of reasons, mostly due to limitations in the duplication and ssa updating code that may prevent this from being a single jump threading path. Anyway... So we process A first. That creates a duplicate of 192, removes the control statement in the duplicate and wires the duplicate to reach 194. But note that we already know that if we traverse 192->194, then we must reach 202. So this new edge 192'->194 is actually threadable too, but we're not going to see it until the next DOM pass. Obviously we'd prefer to just DTRT and not leave the jump thread in the IL. That's easily accomplished by handling non-loop jump threads in a post-order traversal When we do that, we'll first handle thread path B which will redirect the 192->194 edge to 192->194' and the right things "just happen" when we process thread path A and we avoid the false positive uninit warning. Bootstrapped and regression tested on x86_64. Wstringop-truncation is ping-ponging, but not due to this patch AFAICT. Also verified by visual inspection that the first DOM pass fully threaded the code in question when using a local branch that has my removal of threading from tree-vrp patches installed and bootstrapping that branch. Installing on the trunk. Jeff
