search for: __aeabi_

...September 2014 02:18, Saleem Abdulrasool <compnerd at compnerd.org> > wrote: > > The current implementations actually return 0. Can you point out where > that > > doesn't hold please? > > With the current implementation... > > int foo(int a) { > return __aeabi_idiv0(a); > } > > returns 'a', while: > > int bar(int a) { > return __aeabi_idiv(a, 0); > } > > returns zero. > > > > Quoting the RTABI: > > > > int __aeabi_idiv0(int return_value); > > long long __aeabi_ldiv0(long long return_...

> 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...

...to Golin wrote: > I'm in favour for adding them ASAP, but we might need an ifdef to avoid > creating unnecessary (or conflicting) symbols for non-EABI targets. Sure, it makes sense. > A proper solution would be to have: > > LOCAL_LABEL(divby0): > #ifdef __ARM_EABI__ > b __aeabi_idiv0 > #else > mov r0, #0 > JMP(lr) > #endif > > And make both __aeabi_{i,l}div0 return 0. > > I'm hoping both parts of the ifdef to generate *identical* code, but > with the benefit that we can change the behaviour of div0 by > overriding the function's im...

...ument. > Fair enough. However, the point is that emulating GCC's behavior of the exception is what I was referring to. > Today we return either zero (in divmod/div/mod) or the argument (when > calling div0 directly), and that's just wrong. Quoting the RTABI: 1. int __aeabi_idiv0(int return_value); long long __aeabi_ldiv0(long long return_value); The *div0 functions: 􏰁 Return the value passed to them as a parameter. Is my copy out of date? > > Why 0 and not infinity? Or some other value? > > Because 0 is what it was before. > > ch...

On Fri, Sep 5, 2014 at 11:32 AM, Jonathan Roelofs <jonathan at codesourcery.com > wrote: > Sergey, > > Not that it'll save you much hassle, but here's an implementation of > __aeabi_idiv0 and __aeabi_ldiv0 that I've been sitting on for a while. > > I vaguely remember compnerd suggesting that I don't commit them to > compiler_rt, but I don't remember why. > I did dig into this further and it seems that they are, in fact, considered part of the RT-ABI :-(...

On Sat, Sep 6, 2014 at 3:40 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 6 September 2014 22:46, Saleem Abdulrasool <compnerd at compnerd.org> > wrote: > > I did dig into this further and it seems that they are, in fact, > considered > > part of the RT-ABI :-(. Ive committed a simple conforming > implementation in > > SVN r217322. > >

Hi, There are several places in compiler-rt which refer to __aeabi_idiv0. For example, in lib/builtins/arm/udivsi3.S: #ifdef __ARM_EABI__ b __aeabi_idiv0 #else JMP(lr) #endif At the same time there is no definition of it. It looks as if it was done intentionally so that third-party could provide custom handler for division by zero. IMHO It's not ver...

...discussing this with Tim on IRC and he raised the valid question > of a pure mod operation being faster when emulated as it doesn't have to > keep track of the quotient. So it really boils down to whether it has a > fancy enough dress to be called a feature. ...but it should be using __aeabi_*mod in that case. Joerg

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

Hi folks, I've updated the configuration for my libcxx buildbot (r220701) to pass some additional flags to compilation, including setting the CPU (so it won't need to use soft divide) and link flags + compiler-rt dependency to lit (so it won't fail with __aeabi_* symbols missing). Most problems should be all fixed once we reload the configuration in the build master. Right now, there's only one failure remaining, which I'm investigating. backtrace_test.cpp:59: int main(): Assertion `nothrow_ntraced > 1' failed. cheers, --renato

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) ended up not adopting it and using those GNU functions instead. If NetBSD uses the aeabi ones instead, it probably needs some extra checks added to the code. I believe...

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, all I used Clang to compile an ARM-v6m project. The runtime library is from GNU-ARM. But as I used 'memcpy' function, an error 'undefined reference to `__aeabi_memcpy' was emitted by linker. Does it mean that I must use LLVM compiler-RT instead? Thanks a lot. -------------- Steven ***************************** Legal Disclaimer ***************************** "This email may contain confidential and privileged material for the sole use of the inten...

...> 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) ended up > not adopting it and using those GNU functions instead. > > If NetBSD uses the aeabi ones instead, it probably needs some extra > checks add...

> 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