[
https://issues.apache.org/jira/browse/GROOVY-12538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18132835#comment-18132835
]
ASF GitHub Bot commented on GROOVY-12538:
-----------------------------------------
paulk-asert opened a new pull request, #3053:
URL: https://github.com/apache/groovy/pull/3053
… when an operand is NaN
When both operands of a comparison are primitive double or float values, the
comparison was compiled to DCMPG (FCMPG) for every ordered operator. DCMPG
pushes 1 when either operand is NaN, so > and >= evaluated 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), which Groovy already gave
for two Double objects.
BinaryExpressionWriter gains a getCompareCode(int) hook, used by
writeStdCompare, and the double and float helpers choose the instruction per
operator. Comparisons through Groovy's number comparison (mixed operand types,
== on Double objects) and <=> are unchanged.
> 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
> Priority: Major
>
> 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)
