can/should autoincrement get optimized away?

can/should autoincrement get optimized away?

[John Breitenbach]

I finally got to the bottom of some "unexpected behavior" from the 
amreb-linux target of the 4.1.2 compiler.

I'm hoping that someone can say if is this an optimization bug 
(optimizes away too much) or a problem with this code.

extern int ReadChar( char *p);
/* grab a character from input buffer if available, or make a call to 
get a chunk */
#define READCHAR(p) \
((p->bufposP >= p->inbufendm1P) ? (ReadChar(p)) : \
(*(unsigned char *)(p->bufposP++)))

    for(bytesread = 0; bytesread < len; bytesread++)
      {
        int ch = READCHAR(p);
        if(ch < 0) break;
        htP->threshP[bytesread] = ch;
        /* discard every other byte. */
        if( READCHAR(p) < 0) break;
      }

With the armeb-linux compiler at -O2, in the second invocation of 
READCHAR, the compiler optimizes away the load from bufposP AND the 
post-increment.  Its clear that there's no point in doing the load since 
its only needed to conditionally break out of the loop, and an unsigned 
char can't be less-than zero.  However, can't make up my mind as to 
whether or not it should be allowed to optimize away the 
post-increment.  For the first invocation of READCHAR, the compiler 
generates a conditional load byte with post-increment instruction.

This code has worked on perhaps 7 different architectures over that last 
10 years, using gcc and serveral other compilers.

Thanks, JB

Re: can/should autoincrement get optimized away?

[Jim Wilson]

John Breitenbach wrote:
> char can't be less-than zero.  However, can't make up my mind as to 
> whether or not it should be allowed to optimize away the 
> post-increment. 

It is not OK to optimize away the post-increment.  This is a gcc 
optimization bug.

Jim