search for: __umoddi3

...e using the assembly versions of the "di" division routines on > i386. Except when compiler-rt is built with MSVC because MSVC can't parse > the at&t assembly syntax. Again: my offer to provide these routines still stands! I have OPTIMISED __divdi3, __moddi3, __udivdi3 and __umoddi3 in Intel syntax, wrapped as inline files into an NMakefile, for use with ML.EXE. For the optimisations see the patch I sent last week. Since Howard Hinnant is NO MORE with LLVM: who is the CURRENT code owner and reviewer for the builtins library, especially for x86? I'm asking this SIMPLE que...

...__udivmoddi4 (254 instructions) __moddi3 (51 instructions) calls __udivmoddi4 (254 instructions) __divmoddi4 (36 instructions) calls __divdi3 (37 instructions) which calls __udivmoddi4 (254 instructions) __udivdi3 (8 instructions) calls __udivmoddi4 (254 instructions) __umoddi3 (33 instructions) calls __udivmoddi4 (254 instructions) JFTR: the subdirectory compiler-rt/lib/builtins/i386/ contains FAR better (although suboptimal) __divdi3, __moddi3, __udivdi3 and __umoddi3 routines written in assembler, which SHOULD be shipped with clang_rt.builtins-i386.l...

...tuff`. As can be seen here, the reverse is true for both the GNU binutils and XPG4 versions of `nm' : -bash-3.2$ /usr/xpg4/bin/nm -p -u `find . -name libLLVMCore.a` | head ./Debug/lib/libLLVMCore.a[AsmWriter.o]: 0000000000 U __assert 0000000000 U __clzdi2 0000000000 U __udivdi3 0000000000 U __umoddi3 0000000000 U _GLOBAL_OFFSET_TABLE_ 0000000000 U _ZdaPv 0000000000 U _ZdlPv -bash-3.2$ /usr/bin/nm -p -u `find . -name libLLVMCore.a` | head ./Debug/lib/libLLVMCore.a[AsmWriter.o]: __assert __clzdi2 __udivdi3 __umoddi3 _GLOBAL_OFFSET_TABLE_ _ZdaPv _ZdlPv -bash-3.2$ /u...

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

> On 06/08/2014 02:58 PM, Ady wrote: > >> > >> To be clear, I am not saying there is no bug - there might be. > >> > > > > I performed the following test with several versions of Syslinux: > > > > 1_ Execute: > > 'extlinux --once=non_default_label --install /mnt/sda1' ; > > 2_ In first reboot, the

...e > Info: Symbol __ashrdi3 is defined more than once > Info: Symbol dev_stdcon_w is defined more than once > Info: Symbol __moddi3 is defined more than once > Info: Symbol __syslinux_adv_ptr is defined more than once > Info: Symbol __negdi2 is defined more than once > Info: Symbol __umoddi3 is defined more than once > Info: Symbol __lshrdi3 is defined more than once > Info: Symbol __dtors_end is defined more than once > Info: Symbol __dtors_start is defined more than once > Info: Symbol dev_null_r is defined more than once > Info: Symbol __ashldi3 is defined more than o...

...ternwelten.at> --- Has been since long in the Debian and Ubuntu klibc. diff --git a/klibc/arch/sparc/Makefile.inc b/klibc/arch/sparc/Makefile.inc index 41c23c5..d77030d 100644 --- a/klibc/arch/sparc/Makefile.inc +++ b/klibc/arch/sparc/Makefile.inc @@ -23,25 +23,33 @@ KLIBCARCHOBJS = \ libgcc/__umoddi3.o \ libgcc/__udivmoddi4.o -arch/$(KLIBCARCH)/sdiv.S: arch/$(KLIBCARCH)/divrem.m4 +arch/$(KLIBCARCH)/sdiv.o: arch/$(KLIBCARCH)/sdiv.S + +klibc/arch/$(KLIBCARCH)/sdiv.S: klibc/arch/$(KLIBCARCH)/divrem.m4 @echo 'building $@ from $^' @(echo "define(NAME,\`.div')define(OP,\`div&...

...c --- klibc-0.114_orig/klibc/libgcc/__udivsi3.c 2002-09-16 09:45:47.000000000 -0700 +++ klibc-0.114/klibc/libgcc/__udivsi3.c 2004-02-22 04:39:00.000000000 -0800 @@ -1,5 +1,5 @@ /* - * libgcc/__divsi3.c + * libgcc/__udivsi3.c */ #include <stdint.h> diff -ruN klibc-0.114_orig/klibc/libgcc/__umoddi3.c klibc-0.114/klibc/libgcc/__umoddi3.c --- klibc-0.114_orig/klibc/libgcc/__umoddi3.c 2002-08-27 22:16:15.000000000 -0700 +++ klibc-0.114/klibc/libgcc/__umoddi3.c 2004-02-22 04:39:00.000000000 -0800 @@ -1,5 +1,5 @@ /* - * arch/i386/libgcc/__umoddi3.c + * libgcc/__umoddi3.c */ #include <stdi...

...sfdi); + EXPLICIT_SYMBOL_DEF(__fixunsdfdi); + EXPLICIT_SYMBOL_DEF(__fixunssfdi); + EXPLICIT_SYMBOL_DEF(__floatdidf); + EXPLICIT_SYMBOL_DEF(__floatdisf); + EXPLICIT_SYMBOL_DEF(__lshrdi3); + EXPLICIT_SYMBOL_DEF(__moddi3); + EXPLICIT_SYMBOL_DEF(__udivdi3); + EXPLICIT_SYMBOL_DEF(__umoddi3); #elif defined(_MSC_VER) EXPLICIT_SYMBOL_DEF(_alloca_probe); #endif @@ -157,6 +172,21 @@ { EXPLICIT_SYMBOL(_alloca); EXPLICIT_SYMBOL(__main); + EXPLICIT_SYMBOL(__ashldi3); + EXPLICIT_SYMBOL(__ashrdi3); + EXPLICIT_SYMBOL(__cmpdi2); + EXPLICIT_SYMBOL(__divdi3); +...

...h-4.6p1/packet.c:670: undefined reference to `__ashldi3' /opt/sparc-linux/lib/libcrypto.a(bn_div.o)(.text+0x264): In function `BN_div': : undefined reference to `__udivdi3' /opt/sparc-linux/lib/libcrypto.a(bn_word.o)(.text+0x264): In function `BN_mod_word': : undefined reference to `__umoddi3' /opt/sparc-linux/lib/libcrypto.a(b_print.o)(.text+0x3c4): In function `fmtint': : undefined reference to `__umoddi3' /opt/sparc-linux/lib/libcrypto.a(b_print.o)(.text+0x3fc): In function `fmtint': : undefined reference to `__udivdi3' make: *** [ssh] Erreur 1 -------------------...

Hi all, I've encountered a couple of minor build issues on Solaris that have crept in since 2.5, fixes below: 1. In lib/Target/X86/X86JITInfo.cpp, there is: // Check if building with -fPIC #if defined(__PIC__) && __PIC__ && defined(__linux__) #define ASMCALLSUFFIX "@PLT" #else #define ASMCALLSUFFIX #endif Which causes a link failure due to the non-PLT

...64-Ubuntu 8.04, llvm-gfortran gave me following errors $ llvm-gfortran -Wall hello.f95 -o hellof /home/jli127/LLVM/llvm-gcc/install/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.2.1/../../../../lib64/libgfortran.a(error.o): In function `_gfortrani_gfc_itoa': (.text+0x76): undefined reference to `__umoddi3' /home/jli127/LLVM/llvm-gcc/install/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.2.1/../../../../lib64/libgfortran.a(error.o): In function `_gfortrani_gfc_itoa': (.text+0x8a): undefined reference to `__udivdi3' /home/jli127/LLVM/llvm-gcc/install/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.2....

http://bugzilla.mindrot.org/show_bug.cgi?id=1272 ------- Comment #9 from dtucker at zip.com.au 2007-02-19 23:22 ------- Another thought: do you have multiple instances of libgcc? Perhaps one in /usr/local/lib and one elsewhere? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

Hello > The bitcode was generated by llvm-gcc v2.6 for Mingw32/x86, which is > available for download at the llvm site. > Please let me know, if i should tell more. Well, the answer is pretty obvious then. These calls are not generated by JIT. They are already in your bitcode - they are generated by llvm-gcc. The purpose of these calls were alreade explained by Eli. You should either

...6c36aa22cad 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/pipermail/klibc/attachments/2...

...mips/pipe.o ../mips/vfork.o setjmp.o ../mips/syscall.o + +klib-y += ../../libgcc/__clzsi2.o ../../libgcc/__ashldi3.o +klib-y += ../../libgcc/__ashrdi3.o ../../libgcc/__lshrdi3.o +klib-y += ../../libgcc/__divdi3.o ../../libgcc/__moddi3.o +klib-y += ../../libgcc/__udivdi3.o ../../libgcc/__umoddi3.o +klib-y += ../../libgcc/__udivmoddi4.o + +always := crt0.o +targets := crt0.o diff --git a/usr/klibc/arch/mips/sysstub.ph b/usr/klibc/arch/mips64/sysstub.ph similarity index 96% copy from usr/klibc/arch/mips/sysstub.ph copy to usr/klibc/arch/mips64/sysstub.ph index 3689529..e8a0200 100644 --- a/...

...oddi4 is defined more than once Info: Symbol __ashrdi3 is defined more than once Info: Symbol dev_stdcon_w is defined more than once Info: Symbol __moddi3 is defined more than once Info: Symbol __syslinux_adv_ptr is defined more than once Info: Symbol __negdi2 is defined more than once Info: Symbol __umoddi3 is defined more than once Info: Symbol __lshrdi3 is defined more than once Info: Symbol __dtors_end is defined more than once Info: Symbol __dtors_start is defined more than once Info: Symbol dev_null_r is defined more than once Info: Symbol __ashldi3 is defined more than once Info: Symbol __udivdi...

...rdi3 is defined more than once > > Info: Symbol dev_stdcon_w is defined more than once > > Info: Symbol __moddi3 is defined more than once > > Info: Symbol __syslinux_adv_ptr is defined more than once > > Info: Symbol __negdi2 is defined more than once > > Info: Symbol __umoddi3 is defined more than once > > Info: Symbol __lshrdi3 is defined more than once > > Info: Symbol __dtors_end is defined more than once > > Info: Symbol __dtors_start is defined more than once > > Info: Symbol dev_null_r is defined more than once > > Info: Symbol __ashld...

...ok in my libgfortran.a and it doesn't reference any of the symbols you mention. > /home/jli127/LLVM/llvm-gcc/install/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.2.1/../../../../lib64/libgfortran.a(error.o): > In function `_gfortrani_gfc_itoa': > (.text+0x76): undefined reference to `__umoddi3' This is a library function for doing 64 bit unsigned rem. On a 64 bit machine you shouldn't need to call a library function for this! Are you sure you didn't mix up 64 bit and 32 bit somewhere? > (2) Can I get LLVM bitcode file and run it as llvm-gcc does? > It give following...