search for: softfloat

...ll_works=no i_cv_inotify_works=no i_cv_posix_fallocate_works=no i_cv_signed_size_t=no i_cv_gmtime_max_time_t=32 i_cv_signed_time_t=yes i_cv_mmap_plays_with_write=yes i_cv_fd_passing=yes i_cv_c99_vsnprintf=yes lib_cv_va_copy=yes lib_cv___va_copy=yes lib_cv_va_val_copy=yes SSL_LIBS='/usr/armv5tel-softfloat-linux-gnueabi/usr/include/openssl/aes.h /usr/armv5tel-softfloat-linux-gnueabi/usr/include/openssl/asn1.h /usr/armv5tel-softfloat-linux-gnueabi/usr/include/openssl/asn1_mac.h /usr/armv5tel-softfloat-linux-gnueabi/usr/include/openssl/asn1t.h /usr/armv5tel-softfloat-linux-gnueabi/usr/include/openssl/b...

...ing? H IV0, we are using a lot of different cross-compiler (mainly based on GCC 3.4.x) When I tried to cross-compile FLAC for non-i386 platforms (such as ARM), I use use "configure" in the following way: (cd ~/UPnPTVStack/lgpl-code/flac-1.1.2; make distclean; ./configure --host=armv5b-softfloat-linux --disable-shared CC=/opt/crosstool/gcc-3.4.1-glibc-2.2.5/armv5b-softfloat-linux/bin/armv5b-softfloat-linux-gcc CXX=/opt/crosstool/gcc-3.4.1-glibc-2.2.5/armv5b-softfloat-linux/bin/armv5b-softfloat-linux-g++ LDFLAGS=-lpthread --without-XMMS --without-ogg ; make) Although I did not get any e...

Dear all, I have a problem while compiling the ARM assembly file produced by LLVM arm backend (llc)。 The commands I did are .. llc -march=arm printf.bc -o printf.arm.s arm-softfloat-linux-gnu-as printf.arm.s -o printf.arm.o arm-softfloat-linux-gnu-ld --dynamic-linker /home/toolchain/arm-softfloat-linux-gnu/distributed/arm-softfloat-linux-gnu/lib/ld-2.3.5.so /home/toolchain/arm-softfloat-linux-gnu/arm-softfloat-linux-gnu/lib/crt1.o /home/toolchain/arm-softfloat-linux-gnu/arm-s...

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 not converted >> correctly >> to the particular target format (double precision works as expected). >...

On Mon, 22 Oct 2007, Dale Johannesen wrote: > In principle I think keeping IEEE float and double in an endian- > independent form in the IR files is a good idea. BUT: I'm told > retaining the ability to use files in the existing format is a > requirement (so floats still need to occupy 8 bytes). Since ARM target > doesn't currently work that one is a reasonable

...gt;> 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 thin...

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 the following...

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

Hi Rafael, As you mentioned in the bug, we should only apply this change when hard-float is set, which it is by default on armv7a, I presume. >From that part of the code, I can infer that by the time "MaxAtomicPromoteWidth = 64;", the variable SoftFloat is not properly set, so a simple "if (!SoftFloat)" won't cut in there. It seems SoftFloat is being set on HandleTargetFeatures() which is a virtual method, probably called indirectly. Do you have a better place to set MaxAtomicInlineWidth = 64? cheers, --renato On 13 May 2013 13:56...

...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 description string, so i don't really understand how this is supposed to work. i wonder how other people are cross compiling fo...

On Oct 19, 2007, at 7:23 AM, Dietmar Ebner wrote: > 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). I haven't seen this p...

Identified a while before the release, there is an issue with 64-bit atomics on ARM that was making Clang mis-compile a lot of code, including Clang itself. http://llvm.org/bugs/show_bug.cgi?id=15429 Attached is a patch proposed by Benjamin with the corrections to the test. I'm not an expert on how Clang lowers C11 atomics, but the resulting IR seems correct, and after self-hosting Clang

...d storage box. When I run "make" always get x86_64 binaries. My OS is Gentoo, so I have been able to build using emerge a variety of other programs from source. What am I doing wrong here. (Gentoo doesn't have Dovecot for the arm) I run: ./configure --prefix=/opt --target=armv5tel-softfloat-linux-gnueabi host=armv5tel-softfloat-linux-gnueabi --build=x86_64-pc-linux-gnu --cache-file=config.cache These are some values from config.cache which I think are pertinent: ac_cv_build=${ac_cv_build=x86_64-pc-linux-gnu} ac_cv_c_compiler_gnu=${ac_cv_c_compiler_gnu=yes} ac_cv_env_build_alias_set=...

On Mar 21, 2011, at 3:44 AM, Anton Lokhmotov wrote: >> Adding half float to LLVM IR is *only* reasonable if you have hardware >> that supports half float, or if you want to add softfloat operations >> for these. > Yes, our graphics hardware natively supports some fp16 arithmetic > operations. Ok. >> Just like C compilers need to know sizeof(long), sizeof(void*) and >> many many other target specific details, an OpenCL compiler would need >> to know...

...(as has another llvm-dev poster). Someone > mentioned to me off-list that he managed to get it to build, but I > haven't been able to reproduce the build using his instructions > (I'll post my results in another thread). I've been successfully experimenting with an arm-softfloat-linux-gnu cross-compiler at the time of llvm 2.1. The easiest way to get this working is to use Dan Kegel's crosstool to build a regular gcc toolchain. This will give you binutils, libgcc, and glibc, which you will need anyway. Building llvm-gcc was relatively painless. The only proble...

...appens 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 description string, so i don't > really understand how this is supposed to work. Agree. I think those two match on a...

...lvm-dev poster). Someone > > mentioned to me off-list that he managed to get it to build, but I > > haven't been able to reproduce the build using his instructions > > (I'll post my results in another thread). > > I've been successfully experimenting with an arm-softfloat-linux-gnu > cross-compiler at the time of llvm 2.1. The easiest way to get this > working is to use Dan Kegel's crosstool to build a regular gcc > toolchain. This will give you binutils, libgcc, and glibc, which you > will need anyway. I've been trying to build for the target...

...o: Anton.Lokhmotov at arm.com Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] [PATCH] OpenCL half support On Mar 21, 2011, at 3:44 AM, Anton Lokhmotov wrote: >> Adding half float to LLVM IR is *only* reasonable if you have hardware >> that supports half float, or if you want to add softfloat operations >> for these. > Yes, our graphics hardware natively supports some fp16 arithmetic > operations. Ok. >> Just like C compilers need to know sizeof(long), sizeof(void*) and >> many many other target specific details, an OpenCL compiler would need >> to know...

...n result. The problem is that the helper_function has an important side effect, i.e. it sets the value of f0 but this is not reflected in the IR. so if foo had been changed to: float x, y, z; float foo() { float x = y + z; return 1.0; } now if we convert to float x,y,z; float foo() { softfloat(x=y+z) helper_function(1.0); return int_representation(1.0); } During optimization , this could get converted to: float x,y,z; float foo() { helper_function(1.0); softfloat(x=y+z) return int_representation(1.0); } Because there is no dependency preventing this. now the side effec...

...llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] [PATCH] OpenCL half support > > > On Mar 21, 2011, at 3:44 AM, Anton Lokhmotov wrote: > >>> Adding half float to LLVM IR is *only* reasonable if you have hardware >>> that supports half float, or if you want to add softfloat operations >>> for these. >> Yes, our graphics hardware natively supports some fp16 arithmetic >> operations. > > Ok. > >>> Just like C compilers need to know sizeof(long), sizeof(void*) and >>> many many other target specific details, an OpenCL co...