search for: float_words_big_endian

...:08 AM, Dietmar Ebner wrote: > 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 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 fo...

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 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 d...

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 on...

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

On Oct 22, 2007, at 12:25 PM, Dietmar Ebner wrote: > 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'v...

...onvert.cpp +++ b/gcc/llvm-convert.cpp @@ -5157,11 +5157,6 @@ Constant *TreeConstantToLLVM::ConvertREAL_CST(tree exp) { UArr[0] = RealArr[0]; // Long -> int convert UArr[1] = RealArr[1]; - // FIXME: verify on big-endian targets and cross from big- to little- endian - // targets - if (FLOAT_WORDS_BIG_ENDIAN) - std::swap(UArr[0], UArr[1]); - return ConstantFP::get(Ty, V); } This is known problem. Cross-compilation on targets with different endianness is broken. 2. for gfortran you'll need patch from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097 (note, there are two parts - one attached...

Dietmar, > 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. Hrm, I think I even noticed this during llvm-gcc 4.2 bring up, but i...

hi, 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 not converted correctly to the particular target format (double precision works as expected). it seems the problem is related to