Displaying 5 results from an estimated 5 matches for "real_value_to_target_singl".
Did you mean:
real_value_to_target_single
2007 Oct 22
2
[LLVMdev] troubles with llvm-gcc 4.0 and APFloat on X86_64
...N is false. as far as i've seen, there'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)
...ve seen, there'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.
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 backe...
2007 Oct 22
0
[LLVMdev] cross compiling for arm-softfloat-linux-gnu (was troubles with llvm-gcc 4.0 and APFloat on X86_64)
...;> 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.
> 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...
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