[LLVMdev] cross compiling for arm-softfloat-linux-gnu (was troubles with llvm-gcc 4.0 and APFloat on X86_64)

[Dietmar Ebner]

Dale Johannesen wrote:
> On Oct 22, 2007, at 2:08 AM, Dietmar Ebner wrote:
>> 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 arm-softfloat-linux-gnu, FLOAT_WORDS_BIG_ENDIAN is true while
>> WORDS_BIG_ENDIAN 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.
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 flag to the target machine 
that encodes the floating point endianes (just like "e" vs. "E") and use 
  it when appropriate in the backend to get the target layout 
right(e.g.,  when emitting constants and during target lowering). we'll 
test and post a corresponding patch tomorrow.

anyway, i'm obviously not the first person trying to compile for 
arm-linux and i wonder how other people achieve this, e.g., how are the 
arm-softfloat targets in the nightly tester configured?

i've changed the subject of the thread since the old one was meanwhile 
slightly misleading.

cheers and thanks again for your help,

-
dietmar