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.