From 49f19e7b31fc033ac1e9208580b5be31e2b66b19 Mon Sep 17 00:00:00 2001
From: Siddhesh Poyarekar <siddhesh@sourceware.org>
Date: Thu, 14 Mar 2019 23:08:24 +0530
Subject: [PATCH 67/72] Revert "FFI: Make FP to U64 conversions match JIT
 backend behavior."

This reverts commit f5d424afe8b9395f0df05aba905e0e1f6a2262b8.

The patch breaks test 279, i.e.

  assert(tostring(bit.band(1ll, 1, 1ull, -1)) == "1ULL")

The patch was put in to make the JIT and interpreter behaviour
consistent[1] for float to unsigned int conversions but it ended up
making things worse.  There needs to be a better fix for this.

[1] https://github.com/LuaJIT/LuaJIT/pull/415
---
 src/lj_obj.h | 18 +++++-------------
 1 file changed, 5 insertions(+), 13 deletions(-)

diff --git a/src/lj_obj.h b/src/lj_obj.h
index 72b7ace..c7e4742 100644
--- a/src/lj_obj.h
+++ b/src/lj_obj.h
@@ -942,22 +942,14 @@ static LJ_AINLINE int32_t lj_num2bit(lua_Number n)
 
 #define lj_num2int(n)   ((int32_t)(n))
 
-/*
-** This must match the JIT backend behavior. In particular for archs
-** that don't have a common hardware instruction for this conversion.
-** Note that signed FP to unsigned int conversions have an undefined
-** result and should never be relied upon in portable FFI code.
-** See also: C99 or C11 standard, 6.3.1.4, footnote of (1).
-*/
 static LJ_AINLINE uint64_t lj_num2u64(lua_Number n)
 {
-#if LJ_TARGET_X86ORX64 || LJ_TARGET_MIPS
-  int64_t i = (int64_t)n;
-  if (i < 0) i = (int64_t)(n - 18446744073709551616.0);
-  return (uint64_t)i;
-#else
-  return (uint64_t)n;
+#ifdef _MSC_VER
+  if (n >= 9223372036854775808.0)  /* They think it's a feature. */
+    return (uint64_t)(int64_t)(n - 18446744073709551616.0);
+  else
 #endif
+    return (uint64_t)n;
 }
 
 static LJ_AINLINE int32_t numberVint(cTValue *o)
-- 
2.20.1