search for: div0

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

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

...I wasn't proposing we signal, but that we return zero, 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 i...

...t; part of the RT-ABI :-(. Ive committed a simple conforming > implementation in > > SVN r217322. > > Hi Saleem, > > This implementation will differ from the current sdiv's expected > (return 0) if called from a place that doesn't mov r0, #0 just before > calling div0. > Why not adjust this instead? > ARM and GCC both throw an exception, and on non-EABI ARM, we're > returning zero, so it would be good to have at least one consistent > behaviour. > I think its better to avoid pulling in a dependency on the target libc, particularly if you w...

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

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 :-(. Iv...

...ve this because the common case of Java/Go would require a check in the slow-path to differentiate divide-by-zero from signed overflow. That should be fixed by generalizing the intrinsic so that the two conditions are distinct: %res = call {i32, i1, i1} @llvm.safe.sdiv.i32(i32 %a, i32 %b) %div0 = extractvalue {i32, i1} %res, 1 br i1 %div0, label %trap, label %checkovf checkovf: %ovf = extractvalue {i32, i1} %res, 2 br i1 %div0, label %trap, label %continue trap: call ... unreachable continue: %div = extractvalue {i32, i1} %res, 0 ...or some variation of the abo...

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

We have two subnets with two samba servers (div0 - 150.10.10.1 and div8 - 150.18.18.1 ). If I break the connection between subnets, clients belong to div8 cannot connect locally. All clients have set up wins server to 150.10.10.1 ( div0 ) . If subnets are connect, all is ok ( connecting, browsing). We are using samba 1.9.18p7. smb.conf in div0...

...d require a check in the slow-path to differentiate > > divide-by-zero from signed overflow. That should be fixed by > > generalizing the intrinsic so that the two conditions are distinct: > > > > %res = call {i32, i1, i1} @llvm.safe.sdiv.i32(i32 %a, i32 %b) > > %div0 = extractvalue {i32, i1} %res, 1 > > br i1 %div0, label %trap, label %checkovf > > > > checkovf: > > %ovf = extractvalue {i32, i1} %res, 2 > > br i1 %div0, label %trap, label %continue > > > > trap: > > call ... > > unreachable &g...

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) >> >> Since LR is not preserved, the following JMP(lr) results in an endless loop. >> >> Or is this an intentional chang...

On April 25, 2014 at 1:44:37 PM, Reid Kleckner (rnk at google.com) wrote: Thanks for the writeup! It's very helpful. On Fri, Apr 25, 2014 at 11:49 AM, Filip Pizlo <fpizlo at apple.com> wrote: On April 25, 2014 at 10:48:18 AM, Reid Kleckner (rnk at google.com) wrote: On Fri, Apr 25, 2014 at 10:19 AM, Filip Pizlo <fpizlo at apple.com> wrote: The sdiv operation in LLVM IR only

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

...fferentiate >> > divide-by-zero from signed overflow. That should be fixed by >> > generalizing the intrinsic so that the two conditions are distinct: >> > >> > %res = call {i32, i1, i1} @llvm.safe.sdiv.i32(i32 %a, i32 %b) >> > %div0 = extractvalue {i32, i1} %res, 1 >> > br i1 %div0, label %trap, label %checkovf >> > >> > checkovf: >> > %ovf = extractvalue {i32, i1} %res, 2 >> > br i1 %div0, label %trap, label %continue >> > >> >...

Hi All, I have some data where I am doing fairly simple calculations, nothing more than adding, subtracting, multiplying and dividing. I’m running into a problem when I divide one variable by another and when they’re both 0 I get NaN. I realize that if you divide a non-zero by 0 then you get Inf, which is, of course, correct. But in my case I never get Inf, just NaN because of the structure

Hello everyone I have a couple of questions about the usage of the R function "read.table(.)". My point of departure is that I want to import a matrix (consisting of time and daily stock returns of many stocks) in R. Most of the data is numeric, however some values are missing (blanks) and in other cases I have the character "#DIV/0!" (from excel). My goal is to do some

Hello ! I''m trying to implement something similar to the "multiple updates" section of the Web2.0 chapter of the Agile book. I implemented my version, and nothing is happening. No javascript errors, my logs look fine, page is rendered fine... just no Effect.Highlight. Here is the code: views/causes/cause_home/index.rhtml =============== <%= form_remote_tag(:complete =>

On Wed, Apr 30, 2014 at 10:34 PM, Philip Reames <listmail at philipreames.com> wrote: > Andy - If you're not already following this closely, please start. We've > gotten into fairly fundamental questions of what a patchpoint does. > > Filip, > > I think you've hit the nail on the head. What I'm thinking of as being > patchpoints are not what you think