Displaying 3 results from an estimated 3 matches for "divby0".
Did you mean:
div0
2017 Apr 05
2
compiler-rt, v4.0: arm\udivsi3.S broken for division by zero
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
2014 Sep 06
2
[LLVMdev] [Compiler-RT] [ARM] Where __aeabi_[il]div0 builtins should be implemented?
> 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
2014 Sep 06
3
[LLVMdev] [Compiler-RT] [ARM] Where __aeabi_[il]div0 builtins should be implemented?
...Sat, Sep 06, 2014 at 04:48:20AM -0700, Renato 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...