search for: rtabi

..., instead of the > argument. > 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...

On 11 April 2016 at 02:43, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > This is standard AAPCS, I trully hope neither glibc, newlib or musl's > implementations will corrupt anything more. Normal AAPCS functions are allowed to corrupt d0-d7 and d16-d31, but the RTABI seems pretty explicit that these functions aren't. I think we've got a real problem here. Cheers. Tim.

...o 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 perspective, it's a mess: ELF/COFF/MachO, AAPCS/APCS, RTABI/GNUABI, Little/big-endian, even 32/64-bit on targets with both are all largely orthogonal, but we're lumbered with picking 3-4 names and running with it. There's an argument for moving to an extensible attribute-based system instead, but it'd be a lot of work even if everyone agreed it...

...; 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_value); > > > > The *div0 functions: > > > > 􏰁 Return the value passed to them as a parameter. > > > > Is my copy out of date? > > As I said...

...r libgcc_s variants. The other problem is symbol clashing. If we start including multiple libraries that implement and export the same symbols, we'll be in trouble soon enough. This already happens with --rtlib=compiler-rt and will happen if I include -lgcc_s on libc++abi tests on ARM (for the RTABI part). Having libunwind on its own repository is also not a horrible idea, but I don't know the logistics of that. >> Or we could just say that libc++ *needs* compiler-RT and call it a day. > This makes me uncomfortable (which I gather is what you're going for) in that > not s...

Hi Sandeep, On 17 September 2010 18:52, Sandeep Patel <deeppatel1987 at gmail.com> wrote: > * Only these few renamed libcalls are set as AAPCS because other > libcalls may still want to be AAPCS-VFP. Even the F32 ones? Anton, As discussed, we might better put the FP helpers first, then deal with the REM and Memset later. If Sandeep's patch passes all tests, you can apply that

...easier to review & commit I have split and cleaned-up our original "Support for ARM Run-Time ABI" patch, this part adds support for calls which can be mapped using setLibcallName. Thanks Evzen -------------- next part -------------- A non-text attachment was scrubbed... Name: arm-rtabi.patch Type: application/octet-stream Size: 6090 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100927/5b5a038b/attachment.obj>

On Mon, Sep 27, 2010 at 5:02 PM, Evzen Muller <evzen.muller at arm.com> wrote: > > To make it easier to review & commit I have split and cleaned-up our > original > "Support for ARM Run-Time ABI" patch, this part adds support for calls which > > can be mapped using setLibcallName. As noted in the earlier thread on this, I'm pretty sure that we need to

Hi Anton, could you please look at the second part of RTABI patch (support for REM/UREM) I sent yesterday? http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100927/108762.html Thanks Evzen >> I guess I never saw a float cmp libcall in my testing, which makes >> sense for the platforms I was testing on. >> >> LGTM then....

> 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

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

So, I remember we discussed this earlier this year, but I can't find the thread. The idea is to move libunwind into compiler-rt for the simple reasons below: 1. Unwinding is not exclusive to C++, nor exception handling. 2. Clang still includes libgcc_s and libgcc_eh when using compiler-rt (maybe eh isn't needed, but it was there for libgcc). 3. Testing the libunwind with libc++ on ARM is

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