search for: __umodsi3

The latest binutils (2.21.2) assembler for the PPC64 complains about the .size directive emitted by LLVM as not containing an absolute expression. An example: __umodsi3: .quad .L.__umodsi3,.TOC. at tocbase .previous .L.__umodsi3: mflr 0 [snip] mtlr 0 blr .Ltmp0: .size __umodsi3, .Ltmp0-__umodsi3 The correct size expression should be .Ltmp0-.L.__umodsi3 The code which does this is in AsmPrinter.cpp: // If the...

...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 raised the valid question of a pure mod operation being faster when emulated as it doesn't have to keep track of the quotient. So it really boils down to whether it has a fancy enough dress to be called a feature. Joerg

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 ARM "runtime ABI" and largely > ind...

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

...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 - | grep mod .file "mod.c" bl __modsi3 bl __umodsi3 $ clang -target arm-none-eabi -S mod.c -o - | grep mod .file "mod.c" bl __aeabi_idivmod bl __aeabi_uidivmod This is clearly a bug and should be fixed. Please file a bug in bugzilla and I'll have a look at it. cheers, --renato

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

...st a single IDIV __modsi3 (14 instructions) calls __divsi3 (18 instructions) __divmodsi4 (17 instructions) calls __divsi3 (18 instructions) __udivsi3 (52 instructions) does NOT use DIV, but performs BITWISE division using shifts and additions! __umodsi3 (14 instructions) calls __udivsi3 (52 instructions) __udivmodsi4 (17 instructions) calls __udivsi3 (52 instructions) __muldi3 (41 instructions) performs a "long" multiplication on 16-bit "digits" JFTR: I haven't checked whether clang actually cal...

...__modsi3 (14 instructions) calls __divsi3 (18 instructions) >> __divmodsi4 (17 instructions) calls __divsi3 (18 instructions) >> >> __udivsi3 (52 instructions) does NOT use DIV, but performs BITWISE >> division using shifts and additions! >> __umodsi3 (14 instructions) calls __udivsi3 (52 instructions) >> __udivmodsi4 (17 instructions) calls __udivsi3 (52 instructions) >> >> __muldi3 (41 instructions) performs a "long" multiplication on >> 16-bit "digits" >> >> JF...

...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 raised the valid question > of a pure mod operation being faster when emulated as it doesn't have to > keep track of the quotient. So it really boils down to whether it has a > fancy enough dress to be called a feature. ...but it...

...0723064121|00000|f8a756c36aa22cad C c Add a bunch of libgcc objects. K 41984 O -rw-rw-r-- P klibc/arch/ia64/Makefile.inc ------------------------------------------------ D13 1 I13 9 arch/$(ARCH)/pipe.o \ libgcc/__divdi3.o \ libgcc/__divsi3.o \ libgcc/__udivdi3.o \ libgcc/__udivsi3.o \ libgcc/__umodsi3.o \ libgcc/__umoddi3.o \ libgcc/__udivmodsi4.o \ libgcc/__udivmoddi4.o # Patch checksum=c61569d9 -------------- next part -------------- A non-text attachment was scrubbed... Name: klibc-libgcc-fixes.diff Type: text/x-patch Size: 1114 bytes Desc: not available Url : http://www.zytor.com/piperma...

This fixes a long standing issue where it was not possible to do "make usr/klibc/arch/x86_64/longjmp.o" in the kernel. The principle is that all .o files to be part of klibc are listed with klib-y. For each directory a klib.list file is made that specify all .o file and the final AR then adds all .o files to create libc.a. This patch introduce the infrastructure and converts x86_64 to

...Makefile, and that pathnames should be +# accordingly. +# + +KLIBCARCHOBJS = \ + arch/$(KLIBCARCH)/vfork.o \ + arch/$(KLIBCARCH)/setjmp.o \ + arch/$(KLIBCARCH)/pipe.o \ + arch/$(KLIBCARCH)/syscall.o \ + libgcc/__divdi3.o \ + libgcc/__divsi3.o \ + libgcc/__udivdi3.o \ + libgcc/__udivsi3.o \ + libgcc/__umodsi3.o \ + libgcc/__umoddi3.o \ + libgcc/__udivmodsi4.o \ + libgcc/__udivmoddi4.o + +KLIBCARCHSOOBJS = $(patsubst %o,%.lo,%(KLIBCARCHOBJS)) + +archclean: diff --git a/usr/klibc/arch/ia64/crt0.S b/usr/klibc/arch/ia64/crt0.S new file mode 100644 index 0000000..722276e --- /dev/null +++ b/usr/klibc/arch/ia...

I have updated the klibc patchset based on feedback received. In particular, the patchset has been reorganized so as not to break git-bisect. Additionally, this updates the patch base to 2.6.17-git12 (d38b69689c349f35502b92e20dafb30c62d49d63) and klibc 1.4.8; the main difference on the klibc side is removal of obsolete code. This is also available as a git tree at:

Hello everyone, this is the fourth version of the patch series that introduces ARMv7 with virtualization extensions support in Xen. The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile Express simulator. See the following announce email for more informations about what we are trying to achieve, as well as the original git history: See

Hello everyone, this is the very first version of the patch series that introduces ARMv7 with virtualization extensions support in Xen. The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile Express simulator. See the following announce email for more informations about what we are trying to achieve, as well as the original git history: See