Math.log(17197) produces inconsistent results between javac, jit, Math and StrictMath on various architectures.

[Andrew Haley]

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.