Date: Sun, 16 Feb 2003 00:50:20 +0900 (JST) From: shudo@computer.org To: java@FreeBSD.ORG Subject: Re: Math.pow bug for jdk1.3.1-p8 ? Message-ID: <20030216.005020.894433699.shudo@localhost> In-Reply-To: <20030216014802.A10817@misty.eyesbeyond.com> References: <3E4C9DDD.4040204@gddsn.org.cn> <20030215.175421.1015281127.shudo@localhost> <20030216014802.A10817@misty.eyesbeyond.com>
next in thread | previous in thread | raw e-mail | index | archive | help
From: Greg Lewis <glewis@eyesbeyond.com> > On Sat, Feb 15, 2003 at 05:54:21PM +0900, shudo@computer.org wrote: > > I could confirm __j__ieee754_pow() in libjava.so behaves wrong and one > > in libjava_g.so works correctly. > > > > I also tried writing a test program which calls __j__ieee754_pow() and > > linked the program with e_pow.o, w_sqrt.o, e_sqrt.o, s_fabs.o, > > s_scalbn.o and s_copysign.o generated during compilation process of > > JDK 1.3.1. The program produces the incorrect value (0, not 512). > > > > It is certain that there is a problem around fdlibm, FreeBSD's gcc > > 2.95.4 or how the fdlibm compiled (compiler flags?). > > Sounds like its quite possibly due to problems with optimisation. > Obviously, java_g uses no optimisation when compiling, I agree with you. Next thing we can do to track the cause down is to compile e_pow.c, w_sqrt.c, e_sqrt.c, s_fabs.c, s_scalbn.c and s_copysign.c with different compiler options (-O0, -O2 and so on) and see the result of the ieee754_pow() function. It may be good to supply different options to each source code and identify which source code is badly affected by optimization. We should report the bug of FreeBSD's gcc 2.95.4 to appropriate persons if we could recognize the problem is due to the gcc. Kazuyuki Shudo shudo@computer.org http://www.shudo.net/ 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?20030216.005020.894433699.shudo>