similar to: [LLVMdev] [PATCH] compiler-rt/lib/divsi3.c: do not call udivsi3 directly

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 implementation enabled by

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

On Mon, May 24, 2010 at 2:11 AM, Sébastien Bourdeauducq <sebastien.bourdeauducq at lekernel.net> wrote: > Just bringing that up as I did not get any reply so far. Resending the email isn't really productive; for the given question, the lack of a reply should answer your question. Was there something else you wanted to ask? -Eli > Thanks, > Sébastien > > > On Tuesday

Hi, Would anyone be interested in developing a LatticeMico32 backend in LLVM? LatticeMico32 [1] is an open source microprocessor core designed by Lattice Semiconductor and typically used in FPGAs. It is comparable to the Microblaze processor that you already support. It is already supported by GNU Binutils and GCC (4.5+). It is used by the Milkymist [2] and RTEMS [3] projects. The Milkymist

Just bringing that up as I did not get any reply so far. Thanks, Sébastien On Tuesday 18 May 2010 18:38:41 Sébastien Bourdeauducq wrote: > Hi, > > Would anyone be interested in developing a LatticeMico32 backend in LLVM? > > LatticeMico32 [1] is an open source microprocessor core designed by Lattice > Semiconductor and typically used in FPGAs. It is comparable to the >

On Monday 24 May 2010 14:32:19 Eli Friedman wrote: > Resending the email isn't really productive; for the given question, > the lack of a reply should answer your question. Was there something > else you wanted to ask? I find this message unhelpful at best, if not purely arrogant. You are making an open source compiler, I am making an open source processor: we are fighting for the

Hello Sébastien, Making backends to LLVM is a significant amount of work. If you want somebody to do it for you, either offer some payment or do your own coding. Keep in mind that the bread-and-butter support for LLVM comes from Apple computer so unless the next iPad will start using softcores, be prepared to pursue the other courses of action I laid out. I may be having to write a backend to

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

TB --- 2013-10-31 19:50:43 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2013-10-31 19:50:43 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-31 19:50:43 - starting RELENG_10 tinderbox run for i386/pc98 TB --- 2013-10-31 19:50:43 - cleaning the

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

Hi, tl;dr How can I include LLVM headers and use code from libLLVM*.a files when building compiler-rt libraries? I'd like to create a symbolizer that would be used in AddressSanitizer (ASan) and ThreadSanitizer (TSan) tools which are now part of projects/compiler-rt (as a first step, symbolizer should be able to return file/line info for a given address). I'd like to use and gradually

On May 31, 2012, at 1:20 PM, Chandler Carruth wrote: > On Thu, May 31, 2012 at 1:13 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 31 May 2012 05:02, Alexey Samsonov <samsonov at google.com> wrote: > > Hi, > > > > tl;dr How can I include LLVM headers and use code from libLLVM*.a files when > > building compiler-rt libraries? > >

On Thu, May 31, 2012 at 1:13 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > On 31 May 2012 05:02, Alexey Samsonov <samsonov at google.com> wrote: > > Hi, > > > > tl;dr How can I include LLVM headers and use code from libLLVM*.a files > when > > building compiler-rt libraries? > > LLVM and compiler-rt have different licenses

On Thu, May 31, 2012 at 11:10 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > > #4 is interesting, but a *ton* of work. The Object library, most of > Support > > and System, all would have to sink into this core module, all would have > to > > get dual-licensed (ow!!! how? some of the contributors are around to > agree > > to new license, but

On May 31, 2012, at 6:48 PM, Chandler Carruth wrote: > I'm not sure that this solves the problem. The reason we have dual licenses for the runtime stuff is that we don't want the UIUC license (which has a binary attribution clause) to affect stuff built with the compiler. Saying that "clang -fasan produces code that has to binary attribute the LLVM license" is pretty lame.

On Thu, May 31, 2012 at 5:39 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 31, 2012, at 1:20 PM, Chandler Carruth wrote: > > On Thu, May 31, 2012 at 1:13 PM, Rafael Espíndola < > rafael.espindola at gmail.com> wrote: > >> On 31 May 2012 05:02, Alexey Samsonov <samsonov at google.com> wrote: >> > Hi, >> > >> > tl;dr

On 31 May 2012 05:02, Alexey Samsonov <samsonov at google.com> wrote: > Hi, > > tl;dr How can I include LLVM headers and use code from libLLVM*.a files when > building compiler-rt libraries? LLVM and compiler-rt have different licenses (compiler-rt is dual licensed with the MIT license). Would that be a problem? > > TIA > Cheers, Rafael

> > #4 is interesting, but a *ton* of work. The Object library, most of Support > and System, all would have to sink into this core module, all would have to > get dual-licensed (ow!!! how? some of the contributors are around to agree > to new license, but not all... likely a fair amount of rewrite required to > produce new versions of libraries under the correct license). You

I was trying to build some code today for an ARM7TDMI, which does not have a hardware divider and I noticed that LLVM translated divide instructions into a call into libgcc's udivsi3. Is there any way of removing this library dependency and allowing LLVM's link time optimizer optimize the generated division code (inline it, merge the div/mod if using both, etc)? Thanks much, Arlen

I just upgraded one of my DCs ununtu 20.04 -> 22.04 and samba 4.18 -> 4.19, but the Dc is not yet working again. systemctl status samba-ad-dc shows: Dec 05 12:48:39 cobra samba[749]: [2023/12/05 12:48:39.562920, 0] ../../source4/samba/service_task.c:36(task_server_terminate) Dec 05 12:48:39 cobra samba[749]: task_server_terminate: task_server_terminate: [winbindd child process