gcc 3.3 / i386 / -O2 question

[Dave Korn]

> -----Original Message-----
> From: gcc-owner On Behalf Of Gerald Pfeifer
> Sent: 17 November 2004 01:01

> On Tue, 16 Nov 2004, Beschorner Daniel wrote:
> > Thanks a lot for your effort to all who tested this code with me!
> > There is some evidence for a SuSE linux specific problem in 
> my GCC 3.3.3,
> > cause all others could compile it fine even with -O2.
> 
> Fixed in the SUSE LINUX 9.2 system compiler:
> 
>   % gcc -v
>   Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.4/specs
>   Configured with: ../configure --enable-threads=posix --prefix=/usr 
>   --with-local-prefix=/usr/local --infodir=/usr/share/info 
>   --mandir=/usr/share/man --enable-languages=c,c++,f77,objc,java,ada 
>   --disable-checking --libdir=/usr/lib --enable-libgcj 
>   --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib 
>   --with-system-zlib --enable-shared --enable-__cxa_atexit 
> i586-suse-linux
>   Thread model: posix
>   gcc version 3.3.4 (pre 3.3.5 20040809)
>   % gcc x.c -O ; ./a.out
>   -1343238496
>   % gcc x.c -O2 ; ./a.out
>   -1343238496


  Excuse me for butting in, but I don't understand what makes anyone think this
code _ought_ to produce the same results at different -O levels[*].  The C
language spec is explicit that this is undefined behaviour.  I really can't
understand why people are insisting that multiplying lots of positive numbers
together is somehow *supposed* to produce a negative result and the compiler is
somehow "doing something wrong" if it doesn't.

  The C language spec is completely explicit on this.  The compiler is entitled
to generate code that is only valid under the assumption that the C code being
compiled is valid.  Undefined behaviour means exactly that; the compiler is a
data-processing tool, and if the data you feed it with (the C source) is
garbage, you get GIGO.

int H(int X, int Y)
{
        return X*Y;
}
int main()
{
        A=B=C=100000;
        A+=H(B,C);

  Could _anyone_ who thinks there is a real issue here _please_ tell me what
they think the *correct* value of A should be after this statement, and why?
And whether they think it should do the same on a system that uses an underlying
ones-complement integer representation?

  Now what would be more interesting would be to repeat the test with unsigned
ints.  They _are_ supposed to have well-defined overflow behaviour.


    cheers, 
      DaveK

[*] Or even at the same -O level after different compilations.  Or even on
successive runs of the generated executable.  Or whether it should necessarily
produce any results at all.  Or anything.
-- 
Can't think of a witty .sigline today....