On 05/25/2010 09:37 AM, Xerxes Rånby wrote: > On 2010-05-24 20:12, Tom Rodriguez wrote: >> On May 24, 2010, at 5:55 AM, Xerxes Rånby wrote: >> >> >>> When running this testcase using various jvms / architectures i get varying >>> results of the calculated log_result2 and log_result which >>> >>> ARCH+JVM combination log_result (javac) >>> log_result2 (jit) passes regression test? >>> ia32+OpenJDK Server VM (build 14.0-b16, mixed mode) 9.752490228984199 >>> 9.752490228984199 yes >>> arm+OpenJDK Shark VM (build 16.0-b13, mixed mode) 9.75249022898412 >>> 9.752490228984199 no >>> x86_64+OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode) >>> 9.75249022898412 9.752490228984199 no >>> >> The test applies to a bug which was fixed in hs17 so testing with hs14 is >> sure to fail on x86_64 which is where the bug was. The purpose of the test >> is to make sure that the value doesn't change over time which isn't allowed. >> In the original bug the compiler had an intrinsic for log but the >> interpreter wasn't using the same intrinsic so the interpreter and compiler >> could return different answers. So presumably if you test with hs17 x86_64 >> will be fine but I don't know what the problem would be with the ARM port of >> shark. Does it have intrinsics for Math.log? > > Yes ARM port of Shark uses a intrinsic for the Shark JIT. > The Shark JIT uses the LLVM provided math intrinsics for log calculations, > and the Shark Interpreter Zero lets the Math.log class method handle it > and the class in turn uses the StrictMath.log JNI c call internally. > > The reason why I get different results are of course because i use two > different implementations yet mathematically both valid approximations > (+- 1ulps).
That doesn't really explain it, though. How come the LLVM log returns a different value from the C library? Andrew.
