Does "strictfp" affect called/intrinsified Math functions?
joe.darcy at oracle.com
Mon Jan 25 21:20:15 UTC 2021
On 1/25/2021 11:22 AM, Andrew Leonard wrote:
> 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?
> 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
More information about the core-libs-dev