P4
sharedRuntimeMath.hpp defines scalbnA. It has a post-check for integer overflow, and a sufficiently clever compiler might "optimize" away that check and the consequential behavior.
k := (high & 0x7fffffff) >> 20
k += n
if (k <= -54 && n > 50000) ...
That test can never be true without UB integer overflow. Initial k >= 0 and n > 50000, so k+n >= 50000.
Is there a reason to prefer scalbnA over the <math.h> scalbn? scalbnA differs from scalbn in the underflow behavior. scalbnA returns some "tiny" value, whereas scalbn returns (appropriately signed) zero and a range error occurs.
scalbnA also differs in the overflow behavior. scalbnA returns some "huge" value, while scalbn returns HUGE_VAL. I don't know how those values compare.
Related, sharedRuntimeMath.hpp also defines copysignA, which is only used by scalbnA. It can be deleted if we switch to scalbn. If we fix and keep scalbnA then is there a reason to prefer copysignA over the <math.h> copysign?
k := (high & 0x7fffffff) >> 20
k += n
if (k <= -54 && n > 50000) ...
That test can never be true without UB integer overflow. Initial k >= 0 and n > 50000, so k+n >= 50000.
Is there a reason to prefer scalbnA over the <math.h> scalbn? scalbnA differs from scalbn in the underflow behavior. scalbnA returns some "tiny" value, whereas scalbn returns (appropriately signed) zero and a range error occurs.
scalbnA also differs in the overflow behavior. scalbnA returns some "huge" value, while scalbn returns HUGE_VAL. I don't know how those values compare.
Related, sharedRuntimeMath.hpp also defines copysignA, which is only used by scalbnA. It can be deleted if we switch to scalbn. If we fix and keep scalbnA then is there a reason to prefer copysignA over the <math.h> copysign?
- links to
-
Commit(master)
openjdk/jdk/a910b20b
-
Review(master)
openjdk/jdk/25656
-
Review(master)
openjdk/jdk/25917