Does "strictfp" affect called/intrinsified Math functions?

Joe Darcy joe.darcy at
Mon Jan 25 21:20:15 UTC 2021

Hi Andrew,

On 1/25/2021 11:22 AM, Andrew Leonard wrote:
> Hi,
> Can I just check my understanding is correct, in that the following example
> will not actually return a "strictfp" value, because the Math.exp() is not
> strictfp and by default is a non-strictfp Intrinsic inline implementation?
> Thanks
> Andrew
>      private strictfp double strictfpMathExp(double input)
>      {
>        return Math.exp(input);
>      }

The short answer is "no" -- strictfp-ness is *not* an aspect of runtime 
semantics that is dynamically inherited through method calls.

Some more detail, let's say Math.exp had a different Java implementation 
than StrictMath.exp (that is specifically allowed by the API spec). 
Declaring the Math.exp method to be strictfp would *not* (necessarily) 
imply that Math.exp behaved exactly the same as StrictMath.exp since the 
exp approximation algorithm could differ between the two implementation 
in ways not changed by strictfp-ness.

Floating-point parameter values are always strict, that is, always 
32-bit float or 64-bit double. Return values are allowed by have wider 
exponent range, as are intermediates used in expressions. However, in 
practice, Java computations in common JVMs has been all-strict for some 
time; will need to get back to JEP 306 
( soon!



More information about the core-libs-dev mailing list