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
JIT in OTP 27-RC2 passes wrong value to NIF in aarch64 #8433
Comments
Thanks for your report! If you can't share minimized code to reproduce the issue, can you try using |
Thanks, that's a humongous diff though 😅 Can you print out the result of |
Here you have the full function, I renamed things a bit, but all should be good. This version has the bug.
This version doesn't cause the bug (it's the one with the rewrite I have above):
|
Thanks, does |
Yes |
Thanks, can you try out https://github.com/jhogberg/otp/tree/john/jit/fix-invalid-reg-cache/GH-8433 and see if that fixes the issue? |
Yes it does! Thank you for looking into this so fast! |
…H-8433 arm: Add missing clobber of register cache when SUPER_TMP is used
Describe the bug
We are observing consistently in our code what seems like the wrong value is being picked up to pass to a function. This is seen only with JIT and on aarch64 (both Linux and Darwin) in OTP 27. OTP 26.2.3 works with no problems.
The code has the following structure:
f is being called with f(atomA, {[a1], c1}, #record{...}) and we have added an io:format in f2 and we see that OtherAtom is there atomA while YetAnotherAtom has the correct value.
If we rewrite the above code to be like the following the bug disappears, and also disappears if we add an io:format or
put(something,something)
immediately after the line that creates YetAnotherAtom:To Reproduce
Unfortunately, I didn't manage to isolate the issue so I can't really provide a reproduction. Even just by exporting the function and calling it from the shell doesn't trigger the bug.
Expected behavior
The first argument of the f2 function should be taken from OtherAtom and not Atom.
Affected versions
OTP 27, we tested with RC2 and RC3 and both behave the same.
Additional context
I understand that this is most not enough information for you to investigate the issue, but maybe you can give me ideas on what to get you so you can understand the issue better.
The text was updated successfully, but these errors were encountered: