------- Comment #3 from jakub at gcc dot gnu dot org 2009-10-27 16:53 ------- The issue is that for some strange reason VRP sees the loop iterator (which is [0, 4) ) as VARYING. Then the fDum = get(b, b) is called when b is not 3, and get uses the return maLine[nRow].get(nColumn); for nRow < 3. So, VRP figures that in return mpLine->get(nColumn); nColumn (== b) is necessarily [4, 65535] and reports out of bounds access on something that will really never be executed. If VRP figured that b is [0, 4), it would have been able to tell that the bb's are unreachable and not report diagnostics in that case.
I wonder what related runtime failure you are talking about though, this to me looks like a false positive on something that is never executed (although not optimized out at least until *.optimized dump). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41847
