test/numbers.jl fails on 32-bit platform

[rickhg12hs]

$ make test-numbers
    JULIA test/numbers
     * numbers             exception on 1: ERROR: LoadError: test failed: ("0.3" != "0.3")
 in expression: repr(0.1 + 0.2) != "0.3"
 in error at error.jl:19
 in default_handler at test.jl:27
 in do_test at test.jl:50
 in runtests at /usr/local/src/julia/julia/test/testdefs.jl:66
 in anonymous at multi.jl:642
 in run_work_thunk at multi.jl:603
 in remotecall_fetch at multi.jl:676
 in remotecall_fetch at multi.jl:691
 in anonymous at task.jl:1614
while loading numbers.jl, in expression starting on line 318
ERROR: LoadError: LoadError: test failed: ("0.3" != "0.3")
 in expression: repr(0.1 + 0.2) != "0.3"
 in error at error.jl:19
 in default_handler at test.jl:27
 in do_test at test.jl:50
 in runtests at /usr/local/src/julia/julia/test/testdefs.jl:66
 in anonymous at multi.jl:642
 in run_work_thunk at multi.jl:603
 in remotecall_fetch at multi.jl:676
 in remotecall_fetch at multi.jl:691
 in anonymous at task.jl:1614
while loading numbers.jl, in expression starting on line 318
while loading /usr/local/src/julia/julia/test/runtests.jl, in expression starting on line 42

make[1]: *** [numbers] Error 1
make: *** [test-numbers] Error 2
[Rick@steelers julia]$ ./julia -e 'versioninfo()'
Julia Version 0.4.0-dev+2824
Commit 6bc53e6* (2015-01-19 20:14 UTC)
Platform Info:
  System: Linux (i686-redhat-linux)
  CPU: Genuine Intel(R) CPU           T2250  @ 1.73GHz
  WORD_SIZE: 32
  BLAS: libopenblas (DYNAMIC_ARCH NO_AFFINITY Banias)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

Interestingly ...

$ ../julia
               _
   _       _ _(_)_     |  A fresh approach to technical computing
  (_)     | (_) (_)    |  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "help()" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.4.0-dev+2824 (2015-01-19 20:14 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit 6bc53e6* (0 days old master)
|__/                   |  i686-redhat-linux

julia> repr(0.1 + 0.2)
"0.30000000000000004"

julia> include("testdefs.jl")
2-element Array{Union(UTF8String,ASCIIString),1}:
 "/usr/local/src/julia/julia/usr/local/share/julia/site/v0.4"
 "/usr/local/src/julia/julia/usr/share/julia/site/v0.4"      

julia> repr(0.1 + 0.2)
"0.30000000000000004"

julia> include("numbers.jl")
ERROR: LoadError: test failed: ("0.3" != "0.3")
 in expression: repr(0.1 + 0.2) != "0.3"
 in error at error.jl:19
 in default_handler at test.jl:27
 in do_test at test.jl:50
 in include at ./boot.jl:249
 in include_from_node1 at ./loading.jl:128
while loading /usr/local/src/julia/julia/test/numbers.jl, in expression starting on line 318

julia> repr(0.1 + 0.2)
"0.3"

[staticfloat]

These are the reason we set a few make flags on our 32-bit builds. Specifically, we set JULIA_CPU_TARGET=pentium4 explicitly so that we don't run into weird floating-point issues. I believe this is due to a 32-bit processor using its 80-bit float registers, although I could be wrong.

[rickhg12hs]

Why did repr(0.1 + 0.2) change in value before/after including test/numbers.jl?

[tkelman]

Is something potentially leaking state in the numbers test wrt rounding mode maybe? I know if you run the numbers test under gdb there is a SIGFPE from GMP at some point in there.

[rickhg12hs]

get_rounding value doesn't seem to change.

$ ../julia 
               _
   _       _ _(_)_     |  A fresh approach to technical computing
  (_)     | (_) (_)    |  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "help()" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.4.0-dev+2824 (2015-01-19 20:14 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit 6bc53e6* (0 days old master)
|__/                   |  i686-redhat-linux

julia> get_rounding(Float64)
Base.Rounding.RoundingMode{:Nearest}()

julia> 0.1 + 0.2
0.30000000000000004

julia> include("testdefs.jl")
2-element Array{Union(UTF8String,ASCIIString),1}:
 "/usr/local/src/julia/julia/usr/local/share/julia/site/v0.4"
 "/usr/local/src/julia/julia/usr/share/julia/site/v0.4"      

julia> 0.1 + 0.2
0.30000000000000004

julia> get_rounding(Float64)
Base.Rounding.RoundingMode{:Nearest}()

julia> include("numbers.jl")
ERROR: LoadError: test failed: ("0.3" != "0.3")
 in expression: repr(0.1 + 0.2) != "0.3"
 in error at error.jl:19
 in default_handler at test.jl:27
 in do_test at test.jl:50
 in include at ./boot.jl:249
 in include_from_node1 at ./loading.jl:128
while loading /usr/local/src/julia/julia/test/numbers.jl, in expression starting on line 318

julia> 0.1 + 0.2
0.3

julia> get_rounding(Float64)
Base.Rounding.RoundingMode{:Nearest}()

[rickhg12hs]

Perhaps another clue: fma results are unaffected by including test/numbers.jl.

$ ../julia 
               _
   _       _ _(_)_     |  A fresh approach to technical computing
  (_)     | (_) (_)    |  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "help()" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.4.0-dev+2824 (2015-01-19 20:14 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit 6bc53e6* (0 days old master)
|__/                   |  i686-redhat-linux

julia> fma(1.0,0.2,0.1)
0.30000000000000004

julia> include("testdefs.jl")
2-element Array{Union(UTF8String,ASCIIString),1}:
 "/usr/local/src/julia/julia/usr/local/share/julia/site/v0.4"
 "/usr/local/src/julia/julia/usr/share/julia/site/v0.4"      

julia> fma(1.0,0.2,0.1)
0.30000000000000004

julia> include("numbers.jl")
ERROR: LoadError: test failed: ("0.3" != "0.3")
 in expression: repr(0.1 + 0.2) != "0.3"
 in error at error.jl:19
 in default_handler at test.jl:27
 in do_test at test.jl:50
 in include at ./boot.jl:249
 in include_from_node1 at ./loading.jl:128
while loading /usr/local/src/julia/julia/test/numbers.jl, in expression starting on line 318

julia> fma(1.0,0.2,0.1)
0.30000000000000004

[staticfloat]

Hmmm. Actually, I just noticed this happening even on builds with JULIA_CPU_TARGET=pentium4. It looks like this is due to 06e2137. @eschnett care to take a look at this?

[rickhg12hs]

Looks like this is a side effect of fma.

$ ./julia 
               _
   _       _ _(_)_     |  A fresh approach to technical computing
  (_)     | (_) (_)    |  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "help()" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.4.0-dev+2824 (2015-01-19 20:14 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit 6bc53e6* (0 days old master)
|__/                   |  i686-redhat-linux

julia> 0.1 + 0.2
0.30000000000000004

julia> fma(1.0, 1.0, 1.0)
2.0

julia> 0.1 + 0.2
0.3

julia> 

[rickhg12hs]

Got some wacky rounding and fma action going on:

julia> 0.1 + 0.2
0.30000000000000004

julia> get_rounding(Float64)
Base.Rounding.RoundingMode{:Nearest}()

julia> fma(1.0, 1.0, 1.0)
2.0

julia> get_rounding(Float64)
Base.Rounding.RoundingMode{:Nearest}()

julia> 0.1 + 0.2
0.3

julia> set_rounding(Float64, RoundNearest)
0

julia> 0.1 + 0.2
0.30000000000000004

julia> 

[rickhg12hs]

Could this be a libm bug?

julia> a = 1.0
1.0

julia> b = 1.0
1.0

julia> c = 1.0
1.0

julia> 0.1 + 0.2
0.30000000000000004

julia> ccall((:fma,"libopenlibm"),Cdouble,(Cdouble,Cdouble,Cdouble),a,b,c)
2.0

julia> 0.1 + 0.2
0.30000000000000004

julia> ccall((:fma,"libm"),Cdouble,(Cdouble,Cdouble,Cdouble),a,b,c)
2.0

julia> 0.1 + 0.2
0.3

julia> set_rounding(Float64, RoundNearest)
0

julia> 0.1 + 0.2
0.30000000000000004

julia> 

[nalimilan]

Good catch. But your versioninfo() from above states LIBM: libopenlibm. So why would the bug appear when you run the tests? Which distribution are you using, BTW?

[rickhg12hs]

I'm puzzled too regarding libm/libopenlibm. I don't know why fma hoses the rounding mode.

I am currently using 32-bit Fedora 19. I'll be upgrading to F21 soon since F19 has gone EOL.

[rickhg12hs]

This is disturbing. Is there a test that could be run from the REPL that would determine whether libm or libopenlibm is being used? I'm beginning to doubt that libopenlibm is being used.

[staticfloat]

You could profile a loop of math function calls and see what the backtrace
says.

On Wed, Jan 21, 2015, 20:00 rickhg12hs notifications@github.com wrote:

This is disturbing. Is there a test that could be run from the REPL that
would determine whether libm or libopenlibm is being used? I'm beginning
to doubt that libopenlibm is being used.

—
Reply to this email directly or view it on GitHub
#9847 (comment).

[rickhg12hs]

Looks like libopenlibm is being used.

$ ./julia -e '@profile for k=1:1000000 sin(exp(1.0)) end;Profile.print(C=true,cols=90)' | grep libopen
              1   ...../lib/libopenlibm.so; __kernel_sin; (unknown line)
              104 ...../lib/libopenlibm.so; exp; (unknown line)
              5   ...../lib/libopenlibm.so; sin; (unknown line)
               78 ...../lib/libopenlibm.so; sin; (unknown line)
                21 ...../lib/libopenlibm.so; __ieee754_rem_pio2; (unknown line)
                42 ...../lib/libopenlibm.so; __kernel_sin; (unknown line)