Displaying 7 results from an estimated 7 matches for "tanf".
Did you mean:
tan
2007 Jun 16
2
[LLVMdev] Wrong tan
...s 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...
2007 Jun 16
2
[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;
}
2007 Jun 16
0
[LLVMdev] Wrong tan
> Result compiled with llvm-g++ 2.0:
> tan float: -2.18504
> tan double: 0.309336
This may be due to bug 1505.
Ciao,
Duncan.
2007 Jun 16
0
[LLVMdev] Wrong tan
...r situation?
>
I tried a simple "llvm-g++ -o simple tan.bug.cc"
Output:
tan float: -2.18504
tan double: 0.309336
> (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
> reas...
2005 Apr 28
0
[LLVMdev] SimplifyLibCalls Pass -- Help!
...;") -> 0
* strcspn(s,a) -> const_int (if both args are constant)
* strcspn("",a) -> 0
* strcspn(s,"") -> strlen(a)
strstr:
* strstr(x,x) -> x
* strstr(s1,s2) -> offset_of_s2_in(s1)
(if s1 and s2 are constant strings)
tan, tanf, tanl:
* tan(0.0) -> 0.0
* tan(atan(x)) -> x
toascii:
* toascii(c) -> (c & 0x7f)
trunc, truncf, truncl:
* trunc(cnst) -> cnst'
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/a...
2015 Jul 29
2
[LLVMdev] x86-64 backend generates aligned ADDPS with unaligned address
...rnal constant [8 x i64] [i64 60, i64 4, i64 12, i64 20, i64 28, i64 36, i64 44, i64 52]
@offset_array3 = internal constant [8 x i64] [i64 12, i64 20, i64 28, i64 36, i64 44, i64 52, i64 60, i64 4]
declare float @sinf(float)
declare float @acosf(float)
declare float @asinf(float)
declare float @atanf(float)
declare float @ceilf(float)
declare float @floorf(float)
declare float @cosf(float)
declare float @coshf(float)
declare float @expf(float)
declare float @logf(float)
declare float @log10f(float)
declare float @sinhf(float)
declare float @tanf(float)
declare float @tanhf(float)
dec...
2014 Aug 07
3
[LLVMdev] MCJIT generates MOVAPS on unaligned address
MCJIT when lowering to x86-64 generates a MOVAPS (Move Aligned Packed
Single-Precision Floating-Point Values) on a non-aligned memory address:
movaps 88(%rdx), %xmm0
where %rdx comes in as a function argument with only natural alignment
(float*). This x86 instruction requires the memory address to be 16 byte
aligned which 88 plus something aligned to 4 byte isn't.
Here the