search for: __udivdi3

Are there existing "generic" implementations for these functions under the same license as LLVM? By generic I mean C or IR that doesn't use any particular HW intrinsics. I read up on divides in Knuth's Seminumerical book, but decided to use base-2 long division on the first go-around for simplicity. I know it's not very efficient and I'm looking for shortcuts to

On Oct 31, 2008, at 10:13 AM, Daniel M Gessel wrote: > Are there existing "generic" implementations for these functions under > the same license as LLVM? By generic I mean C or IR that doesn't use > any particular HW intrinsics. Hi Daniel, We're working on a complete ground-up implementation of the API vended by libgcc, including these routines, under the LLVM

Hello, I have a bytecode doing 64 bits division and on Mingw32/x86, lli complains it cannot resolve __udivdi3 when running it. Those symbols are all part of libgcc and all present in lli, but they cannot be found by SearchForAddressOfSymbol (not in any DLL). To workaround that, I explicitely define them in Win32/DynamicLibrary.inc if the current target is Mingw32 (patch attached). Anybody had this probl...

...t; We should be 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 t...

...IT BETTER SHOULD NOT, NEVER! __divdi3 (37 instructions) calls __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 assem...

...ings will do strange `stuff`. 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...

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

...defined reference to `__divdi3' ./libssh.a(packet.o)(.text+0xab4): In function `set_newkeys': /usr/src/SparcV8Linux/openssh-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_prin...

> 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

...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 __udivdi3 is defined more than once > Info: Symbol __syslinux_adv_size is defined more than once > Info: Symbol __ctors_end is defined more than once > Info: Symbol __ctors_start is defined more than once > And, indeed, so it was. Someone wants to help chase down the reasons for the additional...

...ror.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.1/../../../../lib64/libgfortran.a(list_read.o): In function `convert_integer': (.text+0xd7c): undefined reference to `__divdi3' /home/jli127/LLVM/llvm-gcc/install/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.2....

...libc-0.114_orig/klibc/libgcc/__moddi3.c 2002-08-27 22:16:15.000000000 -0700 +++ klibc-0.114/klibc/libgcc/__moddi3.c 2004-02-22 04:39:00.000000000 -0800 @@ -1,5 +1,5 @@ /* - * arch/i386/libgcc/__moddi3.c + * libgcc/__moddi3.c */ #include <stdint.h> diff -ruN klibc-0.114_orig/klibc/libgcc/__udivdi3.c klibc-0.114/klibc/libgcc/__udivdi3.c --- klibc-0.114_orig/klibc/libgcc/__udivdi3.c 2002-08-27 22:16:15.000000000 -0700 +++ klibc-0.114/klibc/libgcc/__udivdi3.c 2004-02-22 04:39:00.000000000 -0800 @@ -1,5 +1,5 @@ /* - * arch/i386/libgcc/__divdi3.c + * libgcc/__udivdi3.c */ #include <stdin...

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.

...CHK     include/linux/compile.h   UPD     include/linux/compile.h   CC      init/version.o   LD      init/built-in.o   LD      .tmp_vmlinux1 arch/x86/kernel/built-in.o: In function `timer_interrupt'': /usr/src/buildir/linux-2.6.29.4/arch/x86/kernel/time_32-xen.c:465: undefined reference to `__udivdi3'' make: *** [.tmp_vmlinux1] Error 1 ---------------------------------------------------------   Installation steps:   1. Install Mercurial and Git (hg) :- # apt-get install mercurial gitk 2. Building Xen:- # cd /usr/src # hg clone http://xenbits.xensource.com/xen-3.4-testing.hg # cd xen...

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

...CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 arch/x86/kernel/built-in.o: In function `timer_interrupt'': /usr/src/build/linux-2.6.30.2/arch/x86/kernel/time_32-xen.c:463: undefined reference to `__udivdi3'' make: *** [.tmp_vmlinux1] Error 1 -- Best Regards, Mehdi Sheikhalishahi _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users

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

...the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp at intel.com> All errors (new ones prefixed by >>, old ones prefixed by <<): ERROR: modpost: "fw_arg3" [drivers/mtd/parsers/bcm63xxpart.ko] undefined! >> ERROR: modpost: "__udivdi3" [drivers/vdpa/mlx5/mlx5_vdpa.ko] undefined! --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org -------------- next part -------------- A non-text attachment was scrubbed... Name: .config.gz Type: application/gzip Size: 67354 by...

...; Reported-by: kernel test robot <lkp at intel.com> > > > > All errors (new ones prefixed by >>, old ones prefixed by <<): > > > > ERROR: modpost: "fw_arg3" [drivers/mtd/parsers/bcm63xxpart.ko] undefined! > > >> ERROR: modpost: "__udivdi3" [drivers/vdpa/mlx5/mlx5_vdpa.ko] undefined! > > I don't know where this complaint comes from. When I follow the steps > above to reproduce, I find myself failing on code unrelated to my patch > set so I can get my code compiled: > > drivers/rpmsg/virtio_rpmsg_bus.c:88:...