similar to: [LLVMdev] compiler-rt's arm vfp o<= implementation

On 8 April 2010 02:28, Rodolph Perfetta <rodolph.perfetta at arm.com> wrote: > movhi means mov if unsigned Higher > > movls means mov if unsigned Lower or Same > > > > so depending on the comparison result r0 holds 1 or 0 > Thanks. Now that I understand the assembly, I think there's another problem. libgcc's definition of lesf2 is actually

I am currently trying to compile a pretty simple program to work on an experimental board. It contains an (FPGA-version of) an ARMv4 processor. So basically, I try this (on my Ubuntu 18.04.1 LTS): clang -v --target=arm-none-eabi -c barehello.c -o barehelloCLANG.o clang -v --target=arm-none-eabi -c io.c -o io.o clang -v --target=arm-none-eabi barehelloCLANG.o io.o -o helloCLANGstatic -static

Hello, on the problems cross-building compiler-rt: Tried to follow https://llvm.org/docs/HowToCrossCompileBuiltinsOnArm.html which lead to this cmake: cmake -G "Ninja" ../llvm/projects/compiler-rt/ -DCOMPILER_RT_BUILD_BUILTINS=ON -DCOMPILER_RT_BUILD_SANITIZERS=OFF -DCOMPILER_RT_BUILD_XRAY=OFF -DCOMPILER_RT_BUILD_LIBFUZZER=OFF -DCOMPILER_RT_BUILD_PROFILE=OFF

Hello again! Tried out the small Hello World Setup, worked as intended: root at christian-forschung-virtual-machine:/home/progs# clang -v --target=arm-linux-gnueabihf hello.c -o hello -fuse-ld=lld clang version 8.0.0 (https://git.llvm.org/git/clang.git/ a152c7a4b7ba8f4cb9532ead9a38a7121db43d50) (https://git.llvm.org/git/llvm.git/ 1959ce6f3e01241919968ac1911fd45660239d23) Target:

Hello again Christian, I've posted https://reviews.llvm.org/D55709 to see if we can get the documentation on how to cross-compile compiler-rt improved. I'll be out of office until next year so I may be a bit slow to respond to any follow ups. Peter On Thu, 13 Dec 2018 at 17:10, Peter Smith <peter.smith at linaro.org> wrote: > > Hello Christian, > > I've just

Hello Peter and Lists, thanks a lot, that way it worked out! The final cmake was cmake -G "Ninja" ../llvm/projects/compiler-rt/ -DCOMPILER_RT_BUILD_BUILTINS=ON -DCOMPILER_RT_BUILD_SANITIZERS=OFF -DCOMPILER_RT_BUILD_XRAY=OFF -DCOMPILER_RT_BUILD_LIBFUZZER=OFF -DCOMPILER_RT_BUILD_PROFILE=OFF -DCMAKE_C_COMPILER=/usr/local/myclang/bin/clang -DCMAKE_AR=/usr/local/myclang/bin/llvm-ar

Hello Christian, I've put some comments inline, On Sun, 3 Feb 2019 at 13:11, Christian Richter <christian.richter at hsu-hh.de> wrote: > > Hello again, > > so after I successfully build the compiler-rt for armv6 I tried to > actually use it in compiling a small helloworld for a baremetal arm > (consisting of barehelloCLANG.c and a small io.h + io.c) , but the >

Hello Christian, I'd expect that adding the library paths (-L) from gcc -v should fix the unable to find -lc, -lm but it won't fix the -lclang_rt.builtins-armv6m.a . To get clang_rt.builtins-armv6m.a you will need to cross compile compiler-rt for v6m and copy it to /usr/local/myclang/lib/clang/8.0.0/lib/baremetal . Beware that building compiler-rt for v6m does need quite a bit of fighting

Hello Christian, I reran my script with a similar cmake command to yours. After the build finished the following command from the build directory gave me: find . -name \*builtins.a ./lib/clang/9.0.0/armv6m-none-eabi/lib/libclang_rt.builtins.a ./lib/clang/9.0.0/armv7m-none-eabi/lib/libclang_rt.builtins.a ./lib/clang/9.0.0/armv7em-none-eabi/lib/libclang_rt.builtins.a I hope you see something like

Hi Siarhei, I've got the patch in my hands, sorry for the delay. It takes into account the MC emitting the .fpu when in ASM mode and the build attributes in both ASM and ELF mode. Jason, that's the patch I was talking about today. It's non-invasive and I'll send it no later than Monday, so should be in for the 2.9 release. cheers, --renato

On 27 May 2011 19:47, Jim Grosbach <grosbach at apple.com> wrote: > Not exactly. The distinction is clear, it's just not expressed as an > either/or question. Specifically, the code generator considers NEON to be a > proper superset of VFP3. So if it has only VFP3, that's all it will use. If > it has NEON, it assumes it also has VFP3 and can use either. Indeed. >

I'd greatly appreciate a pointer to where I could download this library. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111130/215348d5/attachment.html>

Hi... I'm trying to install over debian using wine a soft developed in VFP. The installer can be download from here: http://www.huskysoft.com/instalar%20husky%20pos.exe The problem is when I login correctly. It shows me a window with the message: "Se ha detectado un peque?o inconveniente en la configuracion de su pantalla. A continuacion salga del programa y reinicie su equipo."

On 27 May 2011 02:04, David Dunkle <ddunkle at arxan.com> wrote: > In all cases, I get code that looks pretty very the same; its like what > is below. However, I am expecting to see instruction level differences > between the vfp3 and neon versions. When I do the same with gcc 4.2 I do > see differences in the generated code. Hi David, You could see different instructions (as

On May 27, 2011, at 10:49 AM, David Dunkle wrote: > Thanks, that helps a lot. > >> All chips (to date) with NEON have VFP3, so it's safe to assume that a > -mfpu=neon will have VFP3, so all the decisions >> about code generated for VFP3 can safely be assumed by targets with > NEON. > > Just to confirm my understanding, can I correctly say in general that >

On 3 February 2011 10:25, Siarhei Siamashka <siarhei.siamashka at gmail.com> wrote: > I have submitted a bug some time ago to LLVM bugtracker: > http://llvm.org/bugs/show_bug.cgi?id=8931 Hi Siarhei, This is a really silly bug with a simple fix. We have a similar patch here locally, but as this is part of another set of patches we were waiting for it to stabilise. There are some

On Friday 25 February 2011 22:28:14 Jason Kim wrote: > On Fri, Feb 25, 2011 at 12:16 PM, Siarhei Siamashka > > <siarhei.siamashka at gmail.com> wrote: > > On Thursday 03 February 2011 14:14:28 Renato Golin wrote: > >> On 3 February 2011 10:25, Siarhei Siamashka > >> <siarhei.siamashka at gmail.com> > > > > wrote: > >> > I have

Hi, I have submitted a bug some time ago to LLVM bugtracker: http://llvm.org/bugs/show_bug.cgi?id=8931 The problem is that I'm trying to use clang in linux system, running on ARM hardware. And this bug, as trivial as it is, seems to be a major showstopper. I wonder if I'm the only one trying to use LLVM/clang in this configuration or doing something in an unusual way? Anyway, the LLVM

On Fri, Feb 25, 2011 at 12:16 PM, Siarhei Siamashka <siarhei.siamashka at gmail.com> wrote: > On Thursday 03 February 2011 14:14:28 Renato Golin wrote: >> On 3 February 2011 10:25, Siarhei Siamashka <siarhei.siamashka at gmail.com> > wrote: >> > I have submitted a bug some time ago to LLVM bugtracker: >> > http://llvm.org/bugs/show_bug.cgi?id=8931 >>

Thanks, that helps a lot. > All chips (to date) with NEON have VFP3, so it's safe to assume that a -mfpu=neon will have VFP3, so all the decisions > about code generated for VFP3 can safely be assumed by targets with NEON. Just to confirm my understanding, can I correctly say in general that the llc code generator might blur distinctions between NEON and VFP3 when it can do so