http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59932
--- Comment #4 from Zhendong Su <su at cs dot ucdavis.edu> ---
(In reply to Andrew Pinski from comment #3)
> (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.
Andrew, sorry, I'm baffled by your comments above.
Please note:
1) The issue isn't only triggered at -Os, but also at -O2 and -O3.
2) It doesn't affect GCC 4.8.
3) I don't see how changing l to 0xfe has changed anything.
4) Also optimizations shouldn't really change the warnings issued.
Perhaps I have some misunderstandings, so could you clarify? Thanks.
