Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[vm] Floating point discrepancy (-0.0 vs +0.0) between -emu_flavor emu and -emu_flavor jit #6717

Closed
RobinMorisset opened this issue Jan 20, 2023 · 3 comments · Fixed by #6726
Assignees
Labels
bug Issue is reported as a bug team:VM Assigned to OTP team VM

Comments

@RobinMorisset
Copy link
Contributor

RobinMorisset commented Jan 20, 2023

Describe the bug
On the following code:

-module(jit13564).
-compile([export_all]).

f(0) ->
    -f(ok);
f(_) ->
    0 / 18446744073709551615.

wrapper0() ->
    io:write(f(0)).

Running it with cerl -emu_flavor emu -noshell -pa . -s jit13564 wrapper0 -s init stop results in -0.0 (which seems correct to me).
But running it with cerl -emu_flavor jit -noshell -pa . -s jit13564 wrapper0 -s init stop results in 0.0.

Expected behavior
I'd expect to get the same result from arithmetic operations regardless of whether the JIT is active or not.

Affected versions

Additional context
Replacing f by

f(0) ->
    f(ok);
f(_) ->
    - (0 / 18446744073709551615).

makes the program return -0.0 in both emu and jit flavors.

@RobinMorisset RobinMorisset added the bug Issue is reported as a bug label Jan 20, 2023
@bjorng bjorng added the team:VM Assigned to OTP team VM label Jan 21, 2023
@jhogberg
Copy link
Contributor

Thanks for your report!

It's the JIT that does the wrong thing (see 200842d). I've fixed it in #6726

@bjorng bjorng linked a pull request Jan 24, 2023 that will close this issue
jhogberg added a commit that referenced this issue Jan 26, 2023
@jhogberg
Copy link
Contributor

jhogberg commented Feb 1, 2023

Fixed in #6726, to be released in OTP 25.3. Thanks again for your report! :-)

@jhogberg jhogberg closed this as completed Feb 1, 2023
@Olivier-Boudeville
Copy link

Hi, this is probably not a problem, but as, depending on these changes, it may be surprising, this might be worth reporting: certainly that floats shall not be compared based on strict equality, but this allowed me to notice that apparently (perhaps in link with this issue) Erlang 25.3 evaluates some floating-point operations a bit differently from the past versions.
For example an expression that has been evaluating consistently to 2.442000e+01 (probably for years) is now 2.44200000000000017053e+01. Both values are OK, but as a result change may be the sign of a problem, I preferred to report it.

More context: this was detected in a simple test in CI, https://github.com/Olivier-Boudeville/Ceylan-Myriad/blob/352890f711d9f5c128360522c52a98d597f54d25/test/maths/vector4_test.erl#L102 which with 25.3 is now failing with

{"init terminating in do_boot",{{badmatch,[2.200000e+01,5.400000e+01,-6.000000e+00,2.442000e+01]},[{vector4_test,run,0,[{file,"vector4_test.erl"},{line,102}]},{erl_eval,do_apply,7,[{file,"erl_eval.erl"},{line,744}]},{init,start_it,1,[]},{init,start_em,1,[]},{init,do_boot,3,[]}]}}
init terminating in do_boot ({{badmatch,[2.20000000000000000000e+01,5.40000000000000000000e+01,-6.00000000000000000000e+00,2.44200000000000017053e+01]},[{vector4_test,run,0,[{_},{_}]},{erl_eval,do_apply,7,[{_},{_}]},{init,start_it,1,[]},{init,start_em,1,[]},{init,do_boot,3,[]}]})

(again: not a bug, but a surprise)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issue is reported as a bug team:VM Assigned to OTP team VM
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants