http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59932
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek <jakub 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.
There clearly is a loop with undefined behavior if it is every entered (several
of them), but you just never happen to enter it. Whether to warn about bugs in
obviously dead code is a heated debate, some people ask for it, others don't
want it, but in this case whether the compiler knows it is dead code or not
depends on optimizations. GCC doesn't warn about the other loops because they
have multiple exits and the -Waggressive-loop-optimization warning is, in order
to have as few false positives as possible, only used for the most simple
loops.
Anyway, in this case IMHO it is very well worth the false positive in this
case, rather than never warning because we can't be 100% sure if it isn't in
dead code.
After all, we couldn't then warn about
int a[3];
void foo (void)
{
for (int i = 0; i < 4; i++)
a[i]++;
}
just because main might not call foo at all and thus you'd never invoke the
undefined behavior.
