[llvm-bugs] [Bug 47393] New: Conversion from uint64_t to double produces wrong result for rounding downward

[via llvm-bugs]

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

            Bug ID: 47393
           Summary: Conversion from uint64_t to double produces wrong
                    result for rounding downward
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: chfast at gmail.com
                CC: llvm-bugs at lists.llvm.org, neeilans at live.com,
                    richard-llvm at metafoo.co.uk

When floating-point rounding direction is set to "towards negative infinity"
(FE_DOWNWARD) and conversion from uint64_t(0) to double is performed the result
is -0.0 instead of +0.0.

Architecture: x86_64
Clang version: reproducible in all known versions, including trunk
Options: happens for all combinations of -O0, -O2, -frounding-math,
-fsigned-zeros.

Code (-lm is needed)

enum { FE_DOWNWARD = 0x400 };

extern int fesetround(int rounding_direction);

__attribute__((noinline))
double ui64_to_f64(unsigned long x)
{
    return (double)x;
}

int main()
{
    fesetround(FE_DOWNWARD);
    double z = ui64_to_f64(0);
    return __builtin_signbit(z) != 0;  // expected 0
}

Can be played with at https://godbolt.org/z/jvPGqW.

I believe the main issue is in LLVM.

Without -frounding-math the Clang uses uitofp instruction. The reference says
this should be fine in this context as "it is rounded using the default
rounding mode".

With -frounding-math the 
call double @llvm.experimental.constrained.uitofp.f64.i64(i64 %3, metadata
!"round.dynamic", metadata !"fpexcept.ignore")
is used, but the result is wrong nevertheless.

-- 
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/20200902/d9962c36/attachment-0001.html>