http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59999
--- Comment #23 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 12 Feb 2014, pa...@matos-sorge.com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59999 > > --- Comment #22 from Paulo J. Matos <pa...@matos-sorge.com> --- > After some thought, I am concluding this cannot actually be optimized and that > GCC 4.5.4 was better because it was taking advantage of an undefined behaviour > that doesn't exist. > > The thought process is as follows. The whole process has to do with this type > of loop: > void foo (int loopCount) > { > short i; > for (i = 0; (int)i < loopCount; i++) > ... > } > > GCC 4.5.4 was assuming i++ could have undefined behaviour and the increment > was > done in type short. Then i was promoted to int through a sign_extend and > compared to loopCount. This undefined behaviour allows GCC 4.5.4 to generate > an > int scev for the loop. > > In GCC 4.8 or later (haven't tested with 4.6 or 4.7), i++ is known not to have > undefined behaviour. i++ due to C integer promotion rules is: i = (short) > ((int) i + 1). GCC validly simplifies to i = (short) ((unsigned short)i + 1). > This is then sign extended to int for comparison. GCC cannot generate an int > scev because it's not simple: (int) (short) {1, +, 1}_1. > > This can validly loop forever if loopCount > SHORT_MAX. > For example, is loopCount is SHORT_MAX + 1, then when i reaches SHORT_MAX and > is incremented by one the addition is fine because is done in (unsigned short) > and then truncated using modulo 2 (implementation defined behaviour) to short, > therefore never reaching loopCount and looping forever. > > In RTL we get the following sequence: > r4:SI <- [loopCount] > r0:HI <- 0 > > code label... > > ... > > r2:HI <- r1:HI + 1 > r3:SI <- sign_extend r2:HI > > p0:BI <- r3:SI < r4:SI > loop to code label if p0:BI > > I was tempted to simplify this to: > r4:SI <- [loopCount] > r0:SI <- 0 > > code label... > > ... > > r2:SI <- r1:SI + 1 > > p0:BI <- r2:SI < r4:SI > loop to code label if p0:BI > > However this will never have an infinite loop behaviour if r4:SI == SHORT_MAX, > therefore I think that at least in this case this cannot be optimized. > > I am tempted to close the bug report. Richard? Yes. That sounds correct.
