Date: Sat, 15 Feb 2003 21:21:51 +0100 From: Erik Trulsson <ertr1013@student.uu.se> To: Huang wen hui <hwh@gddsn.org.cn> Cc: java@FreeBSD.ORG, stable@freebsd.org Subject: Re: Optimization problem (Re: Math.pow bug for jdk1.3.1-p8 ?) Message-ID: <20030215202151.GA23574@falcon.midgard.homeip.net> In-Reply-To: <3E4E86B8.2040608@gddsn.org.cn> References: <3E4C9DDD.4040204@gddsn.org.cn> <20030215.175421.1015281127.shudo@localhost> <20030216014802.A10817@misty.eyesbeyond.com> <20030216.005020.894433699.shudo@localhost> <3E4E7728.8030803@gddsn.org.cn> <3E4E86B8.2040608@gddsn.org.cn>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Feb 16, 2003 at 02:28:08AM +0800, Huang wen hui wrote:
> This is a simple one:
>
> #include <stdio.h>
>
> #define __LO(x) *(int*)&x
>
> double tst()
> {
> double t1;
>
> t1=2;
> __LO(t1) = 0;
> return t1;
> }
> main() {
> double d = tst();
> printf("%f\n", d);
>
> }
The program above seems to be buggy.
The line
__LO(t1) = 0;
after macro expansion looks like
*(int*)&t1 = 0;
where t1 is declared as a double, i.e. the program is accessing an
object of type double through a pointer to type int.
As far as I can tell this is not allowed by the C standard and
therefore this program has undefined behaviour. This means that a
compiler is allowed to do whatever it wants.
That the program above exhibits different behaviour when compiled with
-O0 (prints 2.000000) and when compiled with -O1 (prints 0.000000)
does not seem to be a bug in the compiler but rather a bug in the
program that happens to be triggered by the optimization process.
--
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-java" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030215202151.GA23574>