search for: __aeabi_idivmod

Hi, I see there is an inconsistency in LLVM libc calls. For a modulo (reminder) operation, clang -target arm-none-linux-gnueabi generates "__modsi3". clang -target arm-none-eabi generates "__aeabi_idivmod" clang -target arm-linux-androideabi generates "__modsi3" Android bionic libc doesn't provide a __modsi3, instead it provides "__aeabi_idivmod". I wonder why no one has seen this issue so far. Is this a known bug ? If so, can I move head and push a custom lowerin...

On 28 July 2015 at 17:52, Sumanth Gundapaneni <sgundapa at codeaurora.org> wrote: > Android bionic libc doesn’t provide a __modsi3, instead it provides > “__aeabi_idivmod”. Hi Sumanth, Have a look at ARMSubtarget.h, functions: bool isTargetAEABI() They control the lowering of DIV/MOD calls in ARMISelLowering.cpp. Maybe Android needs to be in? cheers, --renato

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

...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 -S mod.c -o - | grep mod .file "mod.c" bl __aeabi_idivmod bl __aeabi_uidivmod This is clearly a bug and should be fixed. Please file a bug in bugzilla and I'll have a look at it. cheers, --renato

Folks, I'm working on bug 16387: "clang doesn't produce ARM EABI-compliant modulo runtime function" http://llvm.org/bugs/show_bug.cgi?id=16387 And I need some pointers. I've changed ARMISelLowering::ARMTargetLowering::ARMTargetLowering() to associate __aeabi_idivmod variants to RTLIB::{U,S}DIVREM_* library calls, but now I need to teach the expansion that on AEABI case, the remainder is not on the stack, but on registers. However, SelectionDAGLegalize::ExpandDivRemLibCall() assumes the remainder is *always* on the stack, as is the case for GNU: // Remainde...

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