Bug 356392

Summary: FPU control word not updated on FYL2X with ST(0) = 0
Product: [Developer tools] valgrind Reporter: Ben Noordhuis <info>
Component: vexAssignee: Julian Seward <jseward>
Status: RESOLVED INTENTIONAL    
Severity: normal    
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: RedHat Enterprise Linux   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: t.s

Description Ben Noordhuis 2015-12-08 14:47:35 UTC
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.
Comment 1 Julian Seward 2016-09-15 12:25:14 UTC
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?
Comment 2 Julian Seward 2016-09-15 12:43:15 UTC
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
Comment 3 Julian Seward 2016-09-15 12:45:29 UTC
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.