You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The main problem is that although 0d == -0d is true, it is wrong to treat them as the same. It seems plausible this kind of constant equality check might be applied elsewhere as well.
Second, the side-effect in the if statement is discarded, although I don't know if there is a scenario where this could possibly matter.
The text was updated successfully, but these errors were encountered:
call .deconst before lubbing the types of the branches; make sure treatment is consistent in other places lubs are taken. (Or maybe: Do this in lub/glb itself)
Update Const#equals to differentiate +-0d (it already has similar handling for NaN). I think we can use Double.doubleToRawLongBits(this.value) == Double.doubleToRawLongBits(that.value) (and the equivalent for Float) to handle all the floating point esoterica correctly.
My last comment wasn't accurate: deconst was already called by ptOrLub. The real problem was a new fast path that avoids lubbing, which was added by virtpatmat.
Scala incorrectly optimizes away the if statement (without -optimize) in the following:
The main problem is that although
0d == -0d
is true, it is wrong to treat them as the same. It seems plausible this kind of constant equality check might be applied elsewhere as well.Second, the side-effect in the if statement is discarded, although I don't know if there is a scenario where this could possibly matter.
The text was updated successfully, but these errors were encountered: