http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59999
--- Comment #18 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 6 Feb 2014, pa...@matos-sorge.com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59999 > > --- Comment #17 from Paulo J. Matos <pa...@matos-sorge.com> --- > (In reply to rguent...@suse.de from comment #15) > > On Thu, 6 Feb 2014, pa...@matos-sorge.com wrote: > > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59999 > > > > > > --- Comment #14 from Paulo J. Matos <pa...@matos-sorge.com> --- > > > Something like this which looks much simpler hits the same problem: > > > extern int arr[]; > > > > > > void > > > foo32 (int limit) > > > { > > > short i; > > > for (i = 0; (int)i < limit; i++) > > > arr[i] += 1; > > > } > > > > Exactly the same problem. C integral type promotion rules make > > that i = (short)((int)i + 1) again. Note that (int)i + 1 > > does not overflow, (short) ((int)i + 1) invokes implementation-defined > > behavior which in our case is modulo-2 reduction. > > > > Nothing guarantees that (short)i + 1 does not overflow. > > I am being thick... indeed I forgot to notice that i++ also invokes undefined > behaviour. I guess then GCC sorts that out by casting i into unsigned short > for > the addition and all the remaining issues then unfold. No, i++ doesn't invoke undefined behavior - that's the whole point and GCC got this wrong until it was fixed (4.5 is still broken). The whole point is that limit == SHORT_MAX + 1 and the loop being endless is _valid_ (well, apart from arr[i] then overflowing - looks like an opportunity to derive that i can _not_ overflow ... ;))
