Displaying 5 results from an estimated 5 matches for "real_value_to_target_doubl".
Did you mean:
real_value_to_target_double
2007 Oct 22
2
[LLVMdev] troubles with llvm-gcc 4.0 and APFloat on X86_64
...39;s only a single
> flag for endianess in the llvm target description string, so i don't
> really understand how this is supposed to work.
Agree. I think those two match on all the targets I've tried.
I think the right approach is to use REAL_VALUE_TO_TARGET_SINGLE for
float
and REAL_VALUE_TO_TARGET_DOUBLE for double, then the two endiannesses
can be handled separately.
> i wonder how other people are cross compiling for arm-linux-gnu?
> any help would be highly appreciated!
2007 Oct 22
1
[LLVMdev] cross compiling for arm-softfloat-linux-gnu (was troubles with llvm-gcc 4.0 and APFloat on X86_64)
...ndianess in the llvm target description string, so i don't
>> really understand how this is supposed to work.
>
> Agree. I think those two match on all the targets I've tried.
>
> I think the right approach is to use REAL_VALUE_TO_TARGET_SINGLE for
> float
> and REAL_VALUE_TO_TARGET_DOUBLE for double, then the two endiannesses
> can be handled separately.
just to be sure: we don't want to generate target dependent constants in
the frontend, do we? this would make it imho unnecessarily hard to deal
with them in the backend.
what we're trying to do is to add another fla...
2007 Oct 22
0
[LLVMdev] cross compiling for arm-softfloat-linux-gnu (was troubles with llvm-gcc 4.0 and APFloat on X86_64)
...get description string, so i don't
>>> really understand how this is supposed to work.
>>
>> Agree. I think those two match on all the targets I've tried.
>>
>> I think the right approach is to use REAL_VALUE_TO_TARGET_SINGLE for
>> float
>> and REAL_VALUE_TO_TARGET_DOUBLE for double, then the two endiannesses
>> can be handled separately.
> just to be sure: we don't want to generate target dependent
> constants in
> the frontend, do we? this would make it imho unnecessarily hard to
> deal
> with them in the backend.
I'd rather not...
2007 Oct 22
0
[LLVMdev] troubles with llvm-gcc 4.0 and APFloat on X86_64
hi,
i've got some more things to note. first, the issue is not related to
x86_64 being the host machine - it also happens on i686/linux.
next, i think (one of) the problem(s) is the use of
[HOST_]WORDS_BIG_ENDIAN instead of [HOST_]FLOAT_WORDS_BIG_ENDIAN in
llvm-convert.cpp (see patch below).
this fixes single precision floating point but breaks double precision.
for
2007 Oct 20
2
[LLVMdev] troubles with llvm-gcc 4.0 and APFloat on X86_64
hi,
Dale Johannesen wrote:
> On Oct 19, 2007, at 7:23 AM, Dietmar Ebner wrote:
>> i'm trying to make some experiments with the ARM backend (llvm 2.1)
>> and
>> therefore built an arm-softfloat-linux-gnu toolchain on x86_64 linux.
>>
>> however, the llvm-gcc frontend seems to cause troubles with single
>> precision floating point values, i.e., they are