8000 [vm] Floating point discrepancy (-0.0 vs +0.0) between `-emu_flavor emu` and `-emu_flavor jit` · Issue #6717 · erlang/otp · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

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

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.

Sign up for GitHub

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

Jump to bottom
Closed
RobinMorisset opened this issue Jan 20, 2023 · 3 comments · Fixed by #6726
Closed

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

RobinMorisset opened this issue Jan 20, 2023 · 3 comments · Fixed by #6726
Assignees
@jhogberg
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 •
edited
Loading

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 jhogberg mentioned this issue Jan 23, 2023
Merged
@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
jit: Fix float negation on x64 #6726
Merged
jhogberg added a commit that referenced this issue Jan 26, 2023
@jhogberg
Merge pull request #6726 from jhogberg/john/erts/fnegate-bug-x86_64/G…
e2f4bcb 
…H-6717/OTP-18411

jit: Fix float negation on x64
@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
Contributor

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
Assignees

@jhogberg jhogberg

Labels
bug Issue is reported as a bug team:VM Assigned to OTP team VM
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

jit: Fix float negation on x64 jhogberg/otp
4 participants
@bjorng @RobinMorisset @Olivier-Boudeville @jhogberg
0