Paul King created GROOVY-12538:
----------------------------------
Summary: Primitive double/float > and >= comparisons return true
when an operand is NaN
Key: GROOVY-12538
URL: https://issues.apache.org/jira/browse/GROOVY-12538
Project: Groovy
Issue Type: Bug
Reporter: Paul King
Description:
When both operands of a comparison are primitive double (or float) values,
Groovy
compiles the comparison to a DCMPG (FCMPG) instruction for all four ordered
operators.
DCMPG pushes 1 when either operand is NaN, so > and >= evaluate to true; javac
uses
DCMPL (FCMPL) for > and >= and DCMPG (FCMPG) for < and <=, so that every
comparison
with a NaN operand is false (JLS 15.20.1).
{code:groovy}
double n = Double.NaN
assert !(n > 0.0d) // fails: true
assert !(n >= 0.0d) // fails: true
assert !(n < 0.0d) // passes
assert !(n <= 0.0d) // passes
float f = Float.NaN
assert !(f > 0.0f) // fails: true
{code}
It affects local variables, fields, static fields and parameters declared
double or
float, in dynamic code as well as under @TypeChecked and @CompileStatic. Under
@CompileStatic it also affects Double.NaN itself, which is a primitive there:
Double.NaN > 0.0d is false in dynamic code (the field value is boxed) and true
under
@CompileStatic.
Groovy is also inconsistent with itself: for two Double objects, n > 0.0d
already
gives false, because the runtime unboxes and uses Java's operator.
Cause: BinaryDoubleExpressionHelper.getCompareCode() returns DCMPG and
BinaryFloatExpressionHelper.getCompareCode() returns FCMPG for every operator
(since the primitive-optimisation backends were added in 2011).
This is narrower than GROOVY-3309, which asks for NaN comparisons through
Groovy's
number comparison (mixed types, ==) to follow IEEE 754 as well. Those paths
follow
Double.compareTo/Double.equals by design and are not changed here; <=> already
matches Double.compare for primitives.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
