Bug 15388 - Erroneous output from floating point tan
Summary: Erroneous output from floating point tan
Status: RESOLVED DUPLICATE of bug 14283
Alias: None
Product: glibc
Classification: Unclassified
Component: math (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-23 02:59 UTC by Rahul Sharma
Modified: 2014-06-13 18:18 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rahul Sharma 2013-04-23 02:59:46 UTC
On executing the following code (compiled with g++ 4.6.3 on Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz running Ubuntu 12.04.1 LTS):

#include<cmath>
#include<stdio.h>
using namespace std;
int main()
{
 float f = 4386557896710122704971697171202048.0;
 printf("%.16f\n", tan(f));
 return 0;
}

I get the output as 33554432.0
The expected output is 97800744.0

In hex, this means libm says
tan(0x77584625) = 0x4C000000
However, the output should be 0x4CBA8A45.

The "correct" output was obtained using WolframAlpha
(97800745.2669871207241704332677514328806018068212018723832)
and one other compiler does produce the right output
(in hex 0x4CBA8A45, in decimal 97800744.0)
for the same program.

I know that the input is a bit strange, but looking at the hex
it seems to be a valid representable floating point number.
Using double instead of float makes the problem go away.
Comment 1 Andreas Jaeger 2013-04-23 07:00:56 UTC
Compiling and running the program, I get:
./a.out 
97800744.0000000000000000

Which glibc version and which architecture is your program running on?
Comment 2 Siddhesh Poyarekar 2013-04-23 09:38:19 UTC
This was fixed in 2.17 with the following commit:

commit 7a845b2c237434d4aad790aaba3a973e24ea802f
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Tue Jul 3 17:10:42 2012 +0000

    Fix float range reduction problems (bug 14283).

*** This bug has been marked as a duplicate of bug 14283 ***