[Bug 500] Shark on ARM/x86_64 Math.log incosistent results

[bugzilla-daemon at icedtea.classpath.org]

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=500





------- Comment #5 from xerxes at zafena.se  2010-05-25 11:32 -------
http://bugs.sun.com/view_bug.do?bug_id=6539464(In reply to comment #4)
> I'm sure that will work, but it's a pretty terrible way to fix the problem.
>

At least it are not any worse than how they fixed x86_64 in hs17
http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/819880572f09

When checking the original upsteam x86_64 bug its clear that we must take care
of more than Math.log to fix this issue:
http://bugs.sun.com/view_bug.do?bug_id=6539464

> I'd like to know why the LLVM intrinsic behaves differently.
> 

Yes actually the LLVM intrinsic generates the same mathematically rounded
result as the gcc log intrinsics. On my testsystems they all calculate
log(17197) = 9.752490228984199

Its the OpenJDK bundled StrictMath implementation in 
http://hg.openjdk.java.net/jdk6/jdk6/jdk/file/d48ce7884e7a/src/share/native/java/lang/fdlibm/src/e_log.c
that generates the odd value that are 1 ulp from the mathematically correct
rounded value of 9.752490228984199 and are causing all this fuzz on my test
systems where it calculates:
log(17197) = 9.75249022898412

Recent versions of hotspot like hs17 for x86_64 only use the StrictMath
implementation and thus only generate the 9.75249022898412 result.


-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.