From 49f19e7b31fc033ac1e9208580b5be31e2b66b19 Mon Sep 17 00:00:00 2001 From: Siddhesh Poyarekar 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