http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59932
--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Zhendong Su from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > I don't see why you think this is not undefined behavior.
> > If p1 starts at 1, it cannot turn into 0 as p1++ overflows during the
> > 2147483646th iteration.
>
> Andrew, because "d.f1 > l" is false, so the code simply returns ("return
> b;").
>
> I also always double-check with CompCert's reference interpreter and Frama-C
> if possible.
I see what is happening. It is a true warning that happens due to optimizing
order differences. The place we warn does not know that f is zero the first
time through the loop. Since -Os disables copy headers, we don't get a
different copy of the header. So the code does not optimize away the header.
This is where I am going to say there is a false positive due to optimizing. I
want to close it as won't fix because if we change the value of l to be 0xfe,
then we always warn.
