Date: Sat, 15 Feb 2003 21:21:58 -0800 From: David Schultz <dschultz@uclink.Berkeley.EDU> 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: <20030216052158.GA1488@HAL9000.homeunix.com> 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
Thus spake Huang wen hui <hwh@gddsn.org.cn>: > This is a simple one: > > #include <stdio.h> > > #define __LO(x) *(int*)&x ^^^^^^^^^^^^ The failure of this macro to work as expected is not a compiler bug. The C language makes no provisions to support type punning, and the above is not legal C. When you use gcc -f-string-aliasing -fschedule-insns (which are enabled by -O2), your code might, in fact, break. (I haven't actually observed this for 32-bit quantities and smaller.) The gcc-blessed workaround is to use direct unions (and not pointers thereto), but even that is technically unportable. FWIW, when I last checked, Sun only guaranteed that the JVM would compile with a specific version of gcc and no optimization. That's one of the reasons its performance on ia64 is so terrible. I'm guessing that optimization is unsupported for Sun's JVM for the same reason that it is unsupported in Berkeley Logo; specifically, it probably tries to perform some clever stack manipulation tricks. 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?20030216052158.GA1488>