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
