[llvm-bugs] [Bug 27363] New: @llvm.maxnum.* does not handle signaling NaNs the same way as IEEE 754-2008

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=27363

            Bug ID: 27363
           Summary: @llvm.maxnum.* does not handle signaling NaNs the same
                    way as IEEE 754-2008
           Product: libraries
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: AArch64
          Assignee: unassignedbugs at nondot.org
          Reporter: stoklund at 2pi.dk
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

The @llvm.maxnum.* intrinsic is documented like this:

> Follows the IEEE-754 semantics for maxNum, which also match for libm’s fmax.
>
> If either operand is a NaN, returns the other non-NaN operand.
> Returns NaN only if both operands are NaN.

If one operand is a signaling NaN, this behavior doesn't match IEEE 754-2008:

    @llvm.maxnum.f64(1.0, qNaN) -> 1.0
    @llvm.maxnum.f64(1.0, sNaN) -> 1.0

IEEE 754-2008:

    maxNum(1.0, qNaN) -> 1.0
    maxNum(1.0, sNaN) -> qNaN

I wonder if this changed in the 2008 revision?

The Aarch64 backend translates an fmax() library call to an fmaxnm instruction
which has the 754-2008 semantics for signaling NaNs.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160415/3c37bf0a/attachment.html>