------- Comment #11 from simon dot fenney at imgtec dot com 2010-03-24 13:16
-------
(In reply to comment #10)
> Both sin and sinf are assembly routines so can't probably be affected by
> the gcc used to compile them. See sysdeps/i386/fpu/s_sinf.S and
> sysdeps/i386/fpu/s_sin.S.
>
> I have not seen a working library for your testcase (2.9, built with
> GCC 4.3.2 is broken).
Hmm. The last lot of code I saw was all generic c. Interesting
>
> This isn't a GCC bug but a glibc bug. Clearly glibc uses fsin out of specs.
I can't see that *is* this issue unless fsin is also fundamentally broken. The
Intel "Instruction Set Reference" states fsin works in the range -2^63 to +2^63
and I have just tested a value ~2^7 and got the following
sin(1240093312.000000) (i.e. sin(0x93d4a5 * 2^7))
is computed as -4.581222e-08 (-0x1.898622f829ffep-25)
It SHOULD be ~ -4.581062e-08 (-0x1.8982a036335f2p-25)
Relative error is 3.485e-03%
That is dreadfully inaccurate and corresponds to about 15 bits accuracy instead
of an expected result of about 52~53 bits for a double.
Is there ANY way to get the gcc and glibc developers to talk directly to each
other rather than have me ping-ponging back and forth between the two bugzilla
databases?
--
simon dot fenney at imgtec dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43490
