Created attachment 95936 [details] t.s x86_64 FC23, with valgrind installed from FC repo. $ valgrind --version valgrind-3.11.0 $ uname -a Linux localhost.localdomain 4.2.5-300.fc23.x86_64 #1 SMP Tue Oct 27 04:29:56 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux See the attached test case. Expected output: control_word=3804 result=0.000000 Actual output: control_word=3800 result=0.000000 Evidently the #Z flag isn't set. This trips up the Math.pow() implementation in the V8 JavaScript engine. I haven't checked other instructions. Apologies if this has been reported before. I did a search but I didn't find any bug reports that looked exactly like this issue.
I'm a bit confused by this. My Intel docs (Nov 2015) say: FPU Flags Affected C1 Set to 0 if stack underflow occurred. Set if result was rounded up; cleared otherwise. C0, C2, C3 Undefined. First off, when you say "#Z", do you mean "%eflags.Z" ? This insn only sets C0/1/2/3, not eflags directly. Secondly .. if we speak in terms of the C0/1/2/3 effects, which of them isn't set correctly, according to the Intel doc snippet above?
Oh, you mean the "Zero Divide" flag that is bit 2 of %fpscr. The simulation for FP is somewhat approximate and in particular only %fpscr.{C0,C1,C2,C3,TOP} are simulated. So in your case it's not going to be able to produce the right result. Sorry. See here for more details on FP instruction emulation limitations: http://valgrind.org/docs/manual/manual-core.html#manual-core.limits
Closing this because there's no easy way to fix it, without a big rework of the x87 emulation. Really it should be CANTEASILYFIX rather than WONTFIX, which sounds rather unfriendly.