search for: jakubek

Yes, it's a bug. Please review https://reviews.llvm.org/D31716 On 4/5/2017 3:50 AM, Renato Golin wrote: > On 21 March 2017 at 18:32, Peter Jakubek via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> I think the current implementation for the call "bl __aeabi_idiv0" in >> builtins\arm\udivsi3.S is broken. >> At least for the case that __aeabi_idiv0 returns. (the provided >> implementation does) >...

Hello, I think the current implementation for the call "bl __aeabi_idiv0" in builtins\arm\udivsi3.S is broken. At least for the case that __aeabi_idiv0 returns. (the provided implementation does) Since LR is not preserved, the following JMP(lr) results in an endless loop. Or is this an intentional change of the behavior? The file contains another implementation enabled by

On 29 March 2017 at 02:33, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > sin/cos are libm functions, and so a libcall to those need to honour the > floating point ABI requests. The calling convention to be followed there > should match `-mfloat-abi` (that is, -mfloat-abi=hard => AAPCS/VFP, > -mfloat-abi=soft => AAPCS). Exactly, but they're not, and that's

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

Hello, clang/llvm 4.0.0 generates invalid calls for builtin functions with -mfloat-abi=hard -ffast-math. Small example fail.c: // clang -O2 -target armv7a-none-none-eabi -mfloat-abi=hard -ffast-math -S fail.c -o - extern float sinf (float x); float sin1 (float x) {return (sinf (x));} generates code to pass the parameter in r0 and expect the result in r0. The same code without