search for: __aeabi_uidiv

...code. I believe ELF targets currently decide based > on whether the final part of the triple is "-eabi" or not (as opposed > to "-gnueabi", ...), though I haven't looked at the code recently. Part of the concern is that the same code using / does call __aeabi_idiv and __aeabi_uidiv. Joerg

...-flto now, but it looks like there are now some other problems. First, it seems to be dropping things that I try to KEEP in the linker script, even when I don't use --gc-sections, namely my interrupt vector table. Second, when using thin LTO, it starts trying to link symbols __aeabi_memclr4 and __aeabi_uidiv, which I don't think it should since I am using -ffreestanding -fno-builtins when compiling (with full lto or no lto, it does not try to link these symbols). I just sent an email to register for a bugzilla account, I can report there with a minimally reproducible example for these problems....

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 - | grep mod .file "mod.c" bl __modsi3 bl __umodsi3 $ clang -target arm-none-eabi...

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)

> 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 all, one issue found during the NetBSD/ARM tests is the following. Consider this input for EARM: int f(int a, int b) { return a % b; } unsigned int g(unsigned int a, unsigned int b) { return a % b; } 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? Joerg

Hi, I stopped into IRC to ask about a problem I've been having using Clang in conjunction with LLD to compile and link for an embedded project on Cortex-M ARM processor. First, I am able to separately compile with a call to clang and link with a call to lld, but I cannot use clang to link using lld using the -fuse-ld=lld flag. I have the output from `clang -v -fuse-ld=lld -target

Hello everyone, this is the fourth version of the patch series that introduces ARMv7 with virtualization extensions support in Xen. The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile Express simulator. See the following announce email for more informations about what we are trying to achieve, as well as the original git history: See

Hello everyone, this is the very first version of the patch series that introduces ARMv7 with virtualization extensions support in Xen. The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile Express simulator. See the following announce email for more informations about what we are trying to achieve, as well as the original git history: See