similar to: [LLVMdev] ARM EABI and modulo

Hi Joerg, > At the moment, this will call __modsi3 and __umodsi3, even though those > functions are not part of AAPCS. Should this be considered a lowering > bug in the ARM target? LLVM actually supports both variants, depending on the target. The __aeabi_* functions are part of the ARM "runtime ABI" and largely independent of AAPCS. For whatever reason, Linux (& Darwin)

On Mon, Dec 09, 2013 at 07:56:26AM +0000, Tim Northover wrote: > Hi Joerg, > > > At the moment, this will call __modsi3 and __umodsi3, even though those > > functions are not part of AAPCS. Should this be considered a lowering > > bug in the ARM target? > > LLVM actually supports both variants, depending on the target. The > __aeabi_* functions are part of the

On Mon, Dec 09, 2013 at 01:58:29PM +0000, Renato Golin wrote: > I can see the error, and it's just a bad selection of choices. I was > wrong in assuming that the "eabi" at the end would always force it: > > $ clang -target arm-elf-eabi -S mod.c -o - | grep mod > .file "mod.c" > bl __modsi3 > bl __umodsi3 I was discussing this with Tim on IRC and he

On 9 December 2013 11:51, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > Part of the concern is that the same code using / does call __aeabi_idiv > and __aeabi_uidiv. Hi Joerg, I can see the error, and it's just a bad selection of choices. I was wrong in assuming that the "eabi" at the end would always force it: $ clang -target arm-elf-eabi -S mod.c -o - |

On Mon, Dec 09, 2013 at 03:11:45PM +0100, Joerg Sonnenberger wrote: > On Mon, Dec 09, 2013 at 01:58:29PM +0000, Renato Golin wrote: > > I can see the error, and it's just a bad selection of choices. I was > > wrong in assuming that the "eabi" at the end would always force it: > > > > $ clang -target arm-elf-eabi -S mod.c -o - | grep mod > > .file

> When you decide to work on MachO/Darwin, I want to discuss the problems with ELF vs. EABI (http://llvm.org/PR18187). Well, I'm doing it now to some extent (working on disentangling the ARM backend's various uses of isTargetIOS, isTargetDarwin, isMoonFull as a starting-point). The thing is, the main advantage of Triples is that they're largely GCC-compatible. Without that

Hello, I recognized that compiler-rt's the implementation of __aeabi_memcpy simply branches to memcpy. The implementation of memcpy is not provided. So an externally provided memcpy () has to be used. (also applies to memmove, memset, memclr) On ARM I have seen implementations of memcpy () using floating-point registers (if compiled with NEON support). The is perfectly legal, as memcpy ()

> Looks as though whomever implemented the call to __aeabi_idiv0 wanted > to be conservative for non EABI targets. How could it prevent him from providing default implementation of __aeabi_idiv0() for EABI targets? > AFAIK, gnueabi targets recognize all EABI functions, so that should > work well. Not sure I understand you, nothing in compiler-rt defines these functions, they are

Hi, > Would it be OK to add "ELF" to Triple::EnvironmentType? It seems like a plausible choice since MachO is there. On the other hand, I'm not sure whether it makes sense to make it mutually exclusive with the other members of EnvironmentType (GNU, GNUEABI, EABI). EABI and GNUEABI imply ELF. GNU in practice does not need to imply ELF, but is used in the ARM world as "the

Hello > ./clang -v -emit-llvm -ccc-host-triple arm-none-linux-gnueabi > -I/home/hum/Documents/Projects/llvm_clang/gnuarm-4.0.2/arm-elf/include > -L/home/hum/Documents/Projects/llvm_clang/gnuarm-4.0.2/arm-elf/bin hello.c You forgot about sysroot here. > /home/hum/Documents/Projects/llvm_clang/gnuarm-4.0.2/arm-elf/bin/ld: > unrecognised emulation mode: armelf_linux_eabi >

Ping, Apart from Anton's concerns (which I think are manageable) and Micah's support, I received no reply on this. Does there exist a way to tell MC to generate and ELF container for code on Windows? If not, I'm willing to submit a patch to fix this, but would like some opinions on the best direction to take here. The proposed "llvm::TargetSpec class"

Hello Gergö, Joerg and people on our list With your kind answer, I tried to build a hello world program for ARM(arm-none-linux-gnueabi) on my x86-64 PC. Thank you we verified the generated bitcode. The only thing remained is linking. Let me brief what I did so far. 1. Built Clang/llvm in a way explained in http://clang.llvm.org/get_started.html on Ubuntu 11.10 x86-64 PC 2. Downloaded gcc-4.0

Hello, We're currently working on MC-JIT, focusing on runtime generation and loading of ELF object files, even on non-ELF platforms (i.e. Windows). However, we run into a problem with MC insisting to generate COFF objects on Windows, MachO on Macs and ELF only otherwise, based on the triple. Is there an existing method to generate ELF objects with MC on Windows, without modifying MC? Thanks

When I compile this program *$ cat vararg1-main.c typedef struct { double d; } S0; S0 g1; void foo0(int a, ...); int main(int argc, char **argv) { S0 s0 = { 2.0 }; foo0(1, s0); printf("%f\n", g1.d); * * return 0; }* with this command, *$ clang -target arm-none-linux-gnueabi-gcc -ccc-clang-archs armv7 -emit-llvm vararg1-main.c -S -o vararg1-main.ll -O3* I get this

[+llvmdev, -llvm-dev] (Oopsies, llvmdev doesn't have a hyphen in it like all the others do) On 6/17/14, 10:45 AM, Jonathan Roelofs wrote: > [+llvm-dev, cfe-dev] > > Was "Re: [PATCH] ARM: allow inline atomics on Cortex M" > > On 6/17/14, 10:42 AM, Jonathan Roelofs wrote: >> >> >> On 6/17/14, 9:35 AM, Renato Golin wrote: >>> On 17 June 2014

Hi, here's the canonical helloworld.c #include<stdio.h> int main() { printf("Hello World"); return 0; } In accordance with the cross-compilation LLVM documentation [1], I am trying to target the ARM on the Zedboard [2]. It is an ARM Cortex-A9. The machine I am compiling on is an x86_64 Fedora Linux machine, using clang 3.3. I am failing to generate an executable,

Eric, Attached are patches for llvm and clang that implement this. I've made 'none' a component that must be added explicitly (i.e. don't turn arm-eabi into arm--none-eabi, but rather turn it into arm--unknown-eabi) to try to reduce surprises. It also keeps the normalization logic a bit simpler than it would otherwise have to be. SPIR triples were one place where I was

Dear all, I just sent a patch to llvm-commits about ARM RT-EABI support when choosing "arm/thumb*-eabi-*" triple. It involves three changes described in the path: 1. Floating point helpers (instead of GNU ones). This is supported by GCC as well, in EABI mode. 2. Reminder lowering, using ABI helper too. 3. Memset, changing the order of arguments, as required by the ABI. Please

Hi Everyone, It is getting to be that time again. I've scoured llvm-commits and collected a list of some of the major features we've developed since the last status update (from Feb 21). Please take a look and send me (off list) additions, feedback, corrections, etc. As usual, if I missed something, it's probably because there is such a huge amount of stuff happening,

Hi all, There's been some controversies in the TargetTriple changes and I want to explain it better in the list (to a wider audience) and also propose my plans on how to support the ARM platform better, especially cross-compilation in Clang. All this discussion came as a spin-off of bug 8911 (http://llvm.org/bugs/show_bug.cgi?id=8957)... Today we have three major problems in cross-compiling