-
Notifications
You must be signed in to change notification settings - Fork 251
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
Valgrind bug with fft_small nmod_poly_mul #1366
Comments
The issue is with -0.0. reduce_to_0n is composed of reduce_to_pm1no and reduce_pm1no_to_0n, and the latter really doesn't like the former returning -0.0 (0x800000...) Interesting that valgrind is returning a non-compliant -0.0. I have picture proof of valgrind's crimes |
So, the following minimal example (without any compiler shenanigans getting in the way) shows that valgrind differs from the hardware. It looks like the hardware is doing the right thing according to the standard. Make sure you can reproduce the results on your comp. Also, as suspected, valgrind's
|
Here is the output from my AMD Ryzen 7 4800HS: wbhart@LAPTOP-JUAA3GPC:~$ as mnwe.asm -o mnwe.o && ld mnwe.o -o mnwe && ./mnwe wbhart@LAPTOP-JUAA3GPC:~$ as mnwe.asm -o mnwe.o && ld mnwe.o -o mnwe && valgrind ./mnwe ==21118== |
Also a Ryzen:
|
Reported in Valgrind's Bugzilla. |
Superseded by #2092. |
build/fft_small/test/t-nmod_poly_mul
fails when run withvalgrind
(sample output below).Dan says that this is a bug in valgrind.
The question is: can we isolate the bug to a small piece of code so that it makes sense to report to the valgrind developers?
Is there a workaround?
The text was updated successfully, but these errors were encountered: