> -----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....
