similar to: 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

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 consistent and looks odd as

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

On Tue, Sep 9, 2014 at 1:37 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 9 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

On Mon, Sep 8, 2014 at 1:19 AM, Renato Golin <renato.golin at linaro.org> wrote: > > Why not adjust this instead? > > I was just being conservative. I don't know what else depends on this > library and I don't want to change things outside of my scope. > The current implementations actually return 0. Can you point out where that doesn't hold please? If you

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

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

On Apr 25, 2014, at 2:21 PM, Eric Christopher <echristo at gmail.com> wrote: >> In short, I agree with your observations that these intrinsics are not an >> obvious slam-dunk compared to making the explicit control flow, but I think >> that the intrinsics do give enough flexibility on the LLVM side that it >> would be great if front-ends used them rather than rolling

This way, CPUs that have hardware support for unsigned division do not need to use the slow software emulation. -------------- next part -------------- A non-text attachment was scrubbed... Name: divsi3-no-udivsi.diff Type: text/x-patch Size: 694 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120531/b5527f42/attachment.bin>

I am very much in favor of having a div instruction with well defined div-by-zero and overflow behavior. The undefined behavior on certain values for LLVM intrinsics has been a major pain point for us in Julia, because adding the extra branches just kills performance and we know that there is an X86 instruction that just does what we want. Anyway, this was brought up briefly above, but want to

Are there any updates on when LLVM v4.0 is to be released? Just curious, MartinO -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170301/0811ce97/attachment.html>

Hello, With regards to Peter's comment, I got R to compile on OSF 4.0C, though I'm a little behind on versions. I only have 0.63.3 and haven't found anything newer... All kidding regarding typos aside, I went through that floating point exception business on the Alpha and I just didn't have time to make it work. Someone tipped me on to f2c, which I had used with my (old gcc

I wrote about my problems building R-0.63.3 on a Digital Alpha running OSF V4.0D. Thanks to the suggestion Jonathan.Yuen at tvs.slu.se, I tried using the DEC CC compiler instead of gcc, and it worked just fine. (Seeing that I needed gmake to build, it never occured to me to try DEC CC. It seems that you cannot combine DEC F77 with gcc; I do not have g77 to try.) Below is a set of instructions

I am trying to upgrade to the LLVM v4.0 branch, but I am seeing failures in my TableGen descriptions for conversion from FP32 to FP16 (scalar and vector). The patterns I have are along the lines of: [(set (f16 RF16:$dst), (fround (f32 RF32:$src)))] or: [(set (v2f16 VF16:$dst), (fround (v2f32 VF32:$src)))] and these now produce the errors: error: In CONV_f32_f16: Type inference

CentOS 7.4 client mounting a CentOS 7.4 server filesystem over nfs4. nfs seems to be much slower since the upgrade to 7.4, so I thought it might be nice to mount the directory as v4.0 rather than the new default of v4.1 to see if it makes a difference. The release notes state, without an example: "You can retain the original behavior by specifying 0 as the minor version" nfs(5)

Hi Serge, Thanks for your help. I have looked at the change log, and so far as I can tell, my implementation is pretty much identical to all of the in-tree targets, but I’m missing something and can’t see what it is. I have simplified my TD description to just: def MyCallseqStart : SDNode<"ISD::CALLSEQ_START", SDCallSeqStart<[SDTCisVT<0, i32>,

Hi Martin, Pseudo CALLSEQ_START was changed in r302527, commit message contains details on the changes. However CALLSEQ_END was not modified. If your made changes to ADJCALLSTACKUP to add additional argument, that may result in error. Thanks, --Serge 2017-09-15 19:09 GMT+07:00 Martin J. O'Riordan via llvm-dev < llvm-dev at lists.llvm.org>: > Hi LLVM-Devs, > > I have managed

I am trying to install R-0.63.3 on a Digital Alpha running OSF V4.0D, and having some difficulties. Can anyone help? Also, I found some "oddities" in the installation process. I expect that this message is read by the developers, maybe some of my suggestions can be incorporated into future releases. Please reply to me directly (as well as possibly also to this mailing list): I am not a

Is there maybe a way to consolidate (At the developer level) all of the tools and methods into one concise list. samba is not really tightly integrated with the OS, Is there maybe a way to re-organise the way samba works? maybe to make it completely emulate the way it works on the windows command line? for example make everything integrated into the net command..... net use (file system