similar to: [LLVMdev] compiler-rt: Infinite loop/stack overflow in __modsi3()

Thanks for the confirmation, Steve. Your suggestion looks good to me, but I don't have an environment set up to build the test suite so it may take me a little while to get back to you with a validated patch. A bit of creative grepping yields the following that also look problematic to me: compiler-rt/test/builtins/Unit/absvsi2_test.c: expected = -expected;

Hi, I recently came across the following in __floatsidf in compiler-rt: __floatsidf(int a) { ... if (a < 0) { ... a = -a; In the case where a == INT_MIN, is this negation not undefined behaviour? AIUI this function is used for software emulation on targets that have no hardware floating point support. Perhaps there is an in-built assumption

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

Hi, I see there is an inconsistency in LLVM libc calls. For a modulo (reminder) operation, clang -target arm-none-linux-gnueabi generates "__modsi3". clang -target arm-none-eabi generates "__aeabi_idivmod" clang -target arm-linux-androideabi generates "__modsi3" Android bionic libc doesn't provide a __modsi3, instead it provides

On 28 July 2015 at 17:52, Sumanth Gundapaneni <sgundapa at codeaurora.org> wrote: > Android bionic libc doesn’t provide a __modsi3, instead it provides > “__aeabi_idivmod”. Hi Sumanth, Have a look at ARMSubtarget.h, functions: bool isTargetAEABI() They control the lowering of DIV/MOD calls in ARMISelLowering.cpp. Maybe Android needs to be in? cheers, --renato

Hi @ll, LLVM-7.0.0-win32.exe contains and installs lib\clang\7.0.0\lib\windows\clang_rt.builtins-i386.lib The implementation of (at least) the multiplication and division routines __[u]{div,mod,divmod,mul}[sdt]i[34] shipped with this libraries SUCKS: they are factors SLOWER than even Microsoft's NOTORIOUS POOR implementation of 64-bit division shipped with MSVC and Windows! The reasons: 1.

"Craig Topper" <craig.topper at gmail.com> wrote: > None of the "si" division routines will be used by x86. That was my expectation too. > They exist for targets that don't support the operations natively. > X86 supports them natively so will never use the library functions. So they SHOULD not be built (or at least not shipped) with the builtins library

On Mon, Dec 09, 2013 at 07:56:26AM +0000, Tim Northover wrote: > Hi Joerg, > > > At the moment, this will call __modsi3 and __umodsi3, even though those > > functions are not part of AAPCS. Should this be considered a lowering > > bug in the ARM target? > > LLVM actually supports both variants, depending on the target. The > __aeabi_* functions are part of the

Hi all, Sorry for bothering those not interested. I found that ARM backend will insert a modulo function (like __modsi3) instead of the modulo instruction. I wonder how we can inline the modulo function into the program. Is there any OPTION we can use in the opt or llc? Thanks, Ray -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi all, one issue found during the NetBSD/ARM tests is the following. Consider this input for EARM: int f(int a, int b) { return a % b; } unsigned int g(unsigned int a, unsigned int b) { return a % b; } At the moment, this will call __modsi3 and __umodsi3, even though those functions are not part of AAPCS. Should this be considered a lowering bug in the ARM target? Joerg

Hi A few of us have discussed enhancing the MIR vregs to include support for named-vregs. At the moment named regs are only supported for physical registers and number regs are reserved for vregs. We've decided that to properly implement a syntax for MIR named vregs we first need to reorganized the sigils used for physical registers and external symbols so our proposal is to swap the sigil

The attached patches are against the v0.114 release and cover some of the tweaks I made while playing about testing ARM and Thumb support. Please review and consider applying. Even with the patches, ARM dynamic linking doesn't seem to work and the Thumb test applications seem to have shaken out a Thumb bug in the 2.4.21-rmk2 kernel which I'm still trying to track down. Still more fun to

On 9 December 2013 11:51, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > Part of the concern is that the same code using / does call __aeabi_idiv > and __aeabi_uidiv. Hi Joerg, I can see the error, and it's just a bad selection of choices. I was wrong in assuming that the "eabi" at the end would always force it: $ clang -target arm-elf-eabi -S mod.c -o - |

Hi Joerg, > At the moment, this will call __modsi3 and __umodsi3, even though those > functions are not part of AAPCS. Should this be considered a lowering > bug in the ARM target? LLVM actually supports both variants, depending on the target. The __aeabi_* functions are part of the ARM "runtime ABI" and largely independent of AAPCS. For whatever reason, Linux (& Darwin)

On Mon, Dec 09, 2013 at 01:58:29PM +0000, Renato Golin wrote: > I can see the error, and it's just a bad selection of choices. I was > wrong in assuming that the "eabi" at the end would always force it: > > $ clang -target arm-elf-eabi -S mod.c -o - | grep mod > .file "mod.c" > bl __modsi3 > bl __umodsi3 I was discussing this with Tim on IRC and he

When we discussed this our line of thought was like this: - LLVM IR already uses %name for SSA values which is closer to what a vreg is than to what a physreg is. It would be neat to draw that parallel to llvm IR. - We wanted another sigil for physregs so they are easy to differentiate from vregs to allow people to differentiate vregs/physregs even if they don't know all the physreg names of

Can we use %% for vregs? Seems slightly easier to remember %/%% than $/%. Also, %eax and $some_symbol are already familiar from typical assembly syntax and we probably don't want to break that association. It's all a bikeshed, but being more consistent with assembly is probably a win. -- Sean Silva On Dec 25, 2017 11:31 AM, "Puyan Lotfi via llvm-dev" < llvm-dev at

On Mon, Jan 8, 2018 at 2:27 PM, Matthias Braun <mbraun at apple.com> wrote: > When we discussed this our line of thought was like this: > > - LLVM IR already uses %name for SSA values which is closer to what a vreg > is than to what a physreg is. It would be neat to draw that parallel to > llvm IR. > - We wanted another sigil for physregs so they are easy to differentiate

Hi, Here is a fix for some missing libgcc magic in the ia64 build. A recent problem with udev uncovered this. PPC needs a similar fix. Olaf will send a patch, I imagine. Both unified diff and bk diff (for Bryan) are attached. mh -- Martin Hicks Wild Open Source Inc. mort@wildopensource.com 613-266-2296 -------------- next part -------------- # User: mort # Host:

On Mon, Dec 09, 2013 at 03:11:45PM +0100, Joerg Sonnenberger wrote: > On Mon, Dec 09, 2013 at 01:58:29PM +0000, Renato Golin wrote: > > I can see the error, and it's just a bad selection of choices. I was > > wrong in assuming that the "eabi" at the end would always force it: > > > > $ clang -target arm-elf-eabi -S mod.c -o - | grep mod > > .file