Environment: Windows 10 Pro 64-bit running Ubuntu subsystem (Ubuntu 16.04.2 LTS)

make install failed with

!!! WARNING The following tests failed:

*** [err]: Test HINCRBYFLOAT for correct float representation (issue #2846) in tests/unit/type/hash.tcl Expected condition '[r hincrbyfloat myhash float 1.23] eq {1.23}' to be true ([r hincrbyfloat myhash float 1.23] eq {1.23}) Cleanup: may take some time... OK Makefile:242: recipe for target 'test' failed make[1]: *** [test] Error 1 make[1]: Leaving directory '/home/sami/redis/redis-4.0.6/src' Makefile:6: recipe for target 'test' failed make: *** [test] Error 2

Comment From: kienerj

Can confirm. I get the exact same issue when running make test.

Comment From: ghost

I'm having the same issues! I tried OpenSUSE with the exact same error

Comment From: MicahWoodrowPhillips

18 months later, same issue here.

Comment From: diegoclair

The same here

Comment From: scorpiohjx

The same here

Comment From: oranagra

it seems some compilers on Windows consider long double as a synonym for double. please run uname -a and let me know what you see. we should improve this check to skip that test on this platform:

    # The following test can only be executed if we don't use Valgrind, and if
    # we are using x86_64 architecture, because:
    #
    # 1) Valgrind has floating point limitations, no support for 80 bits math.
    # 2) Other archs may have the same limits.
    #
    # 1.23 cannot be represented correctly with 64 bit doubles, so we skip
    # the test, since we are only testing pretty printing here and is not
    # a bug if the program outputs things like 1.299999...
    if {!$::valgrind && [string match *x86_64* [exec uname -a]]} {

Comment From: yossigo

@oranagra I noticed that as well on WSL which is not really distinguishable from any other Linux/x86_64 environment. I think we may need to relax this test or come up with some way to indicate 80-bit floats are not supported.

Comment From: yossigo

So it seems like WSL sets the FPU control register's PC bits to 10 (double precision) while Linux uses 11 (extended precision). It's possible to use macros in fpu_control.h to query or modify this, although I'm quite reluctant to go into this trouble just for WSL support. That might not be very portable and introduce other hardware-specific issues (header file warns that x86_64 SSE is unaffected by this and requires other configuration, for example).

It might make more sense to just relax the tests. @oranagra what do you think?

Comment From: oranagra

i'm ok with relaxing that test a little bit (but still making sure it hits it's purpose). i.e. find a combination of numbers that have pretty printing using 64 bit long double too.

on the other hand, i'm also ok to add an info field that exposes the precision to clients (maybe it'll be useful for others too).

maybe @guybe7 has some feedback about this (i remember he messed with some other long-double related issues with tests).