llvm dev - Jun 2007 - [LLVMdev] Wrong tan

Hi!

<tangens_bug.cc>

#include <iostream>
#include <cmath>

int main()
{
        float a = 0.3;
        double b = 0.3;

        float result_a = std::tan( a );
        float result_b = std::tan( b );
        std::cout << "tan float: " << result_a <<
std::endl;
        std::cout << "tan double: " << result_b <<
std::endl;
}


<end tangens_bug.cc>

Result compiled with g++ 4.1:
tan float: 0.309336
tan double: 0.309336

Result compiled with llvm-g++ 2.0:
tan float: -2.18504
tan double: 0.309336

Am I missing something or should I file a bug report?

Thanks,
Gonsolo

> Result compiled with llvm-g++ 2.0:
> tan float: -2.18504
> tan double: 0.309336
This may be due to bug 1505.

Ciao,

Duncan.

On Jun 16, 2007, at 12:35 AM, Duncan Sands wrote:
>> Result compiled with llvm-g++ 2.0:
>> tan float: -2.18504
>> tan double: 0.309336
>
> This may be due to bug 1505.
It fails on x86 using x87 floating point, with the inliner not run,
because of 1505, yes.  Gonsolo, is that your situation?

(What happens is, there is  a wrapper in the header file for std::tan 
(float),
like this:

   inline float
   tan(float __x)
   { return __builtin_tanf(__x); }

This wrapper is miscompiled due to 1505; when the inliner is run, no  
problem.)

(But, when opt -std-compile-opts is run, the 'tan' call is evaluated  
at compile
time, while 'tanf' resolves to a libc call.  This is undesirable,  
since the whole
reason tanf exists is that it's supposed to be faster than tan.  Of  
course you
have to be very careful about doing FP operations at compile time, but I
assume this is being done right; it's getting the right answer here,  
anyway.)