--- Comment #5 from jamborm at gcc dot gnu dot org 2008-11-04 15:51 ---
Right, so this is the most simple (albeit not yet tested) patch I've
been able to come up with. I am not sure what overall impact this is
going to have. I'll briefly try to come up with something more
sophisticated
--- Comment #4 from jamborm at gcc dot gnu dot org 2008-10-31 18:01 ---
(In reply to comment #2)
> So what is this? Is the warning logic wrong or is the IR wrong? It seems to me
> that IR is valid.
>
Well, it probabaly isn't. I guess the second index should not ever
exceed its upp
--- Comment #3 from jamborm at gcc dot gnu dot org 2008-10-31 17:52 ---
The test-case in the bug description leads to bogus warnings in the
second run of the VRP pass. Yesterday me and Richi discussed the
possibility of simply not-giving out any warnings in the second runs
(as
--- Comment #2 from manu at gcc dot gnu dot org 2008-10-30 18:43 ---
So what is this? Is the warning logic wrong or is the IR wrong? It seems to me
that IR is valid.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from jamborm at gcc dot gnu dot org 2008-10-30 17:43 ---
Well, yes, we do generate that code. However, the loop is unrolled
later on and the IR code on which the vrp complains later on actually is:
main ()
{
unsigned int ivtmp.27;
unsigned int pretmp.17;
int pretmp
