search for: __moddi3

...mod(long long foo, long long bar) { return foo % bar; } mod: # @mod push ebp | mov ebp, esp | push dword ptr [ebp + 20] | push dword ptr [ebp + 16] | push dword ptr [ebp + 12] | push dword ptr [ebp + 8] | call __moddi3 | jmp __moddi3 add esp, 16 | pop ebp | ret | long long mul(long long foo, long long bar) { return foo * bar; } mul: # @mul push ebp mov ebp, esp push esi mov ecx, dword ptr...

...c -o mini-os.o i686-xen-elf-objcopy -w -G xenos_* -G _start mini-os.o mini-os.o i686-xen-elf-ld -m elf_i386 -T arch/x86/minios-x86_32.lds mini-os.o -o mini-os mini-os.o: In function `bdrv_snapshot_dump'': /home/gzhai/srcs/hg/xen-dev/hv/stubdom/ioemu/block.c:1042: undefined reference to `__moddi3'' /home/gzhai/srcs/hg/xen-dev/hv/stubdom/ioemu/block.c:1042: undefined reference to `__moddi3'' mini-os.o: In function `vmdk_is_allocated'': /home/gzhai/srcs/hg/xen-dev/hv/stubdom/ioemu/block-vmdk.c:547: undefined reference to `__moddi3'' mini-os.o: In function `vm...

...quot; > 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'...

...rms a "long" multiplication on 16-bit "digits" JFTR: I haven't checked whether clang actually calls these SUPERFLUOUS routines listed above. 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 __udivm...

> 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

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

...: > > Info: Symbol __muldi3 is defined more than once > Info: Symbol __divdi3 is defined more than once > Info: Symbol __udivmoddi4 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 tha...

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

...e is one known problem (below), > > but otherwise it works as well as the static PowerPC backend on the test > > suite. > > > > The known problem is that the JIT seems unable to resolve calls to > > external functions that start with "__", such as __eprintf, __moddi3, etc. > > This appears to be something funny in the darwin implementation of dlsym > > (returning null for symbols that are valid if they start with __). If > > anyone has any ideas of how to make this work, we would love to hear them. > > :) > > > > -Chris &gt...

...win32 in our case) being normalized to x86_64-pc-windows-msvc. The breakage occurs because the X86 target lowering doesn't consider x86_64-pc-win32 to be an MSVC environment, and it doesn't lower a few instructions including SREM_I64 to MSVC equivalents (_allrem in this case; we end up with __moddi3 instead). I believe that we should fix this by allowing to invoke the target triple normalization function through the LLVM C API. I would suggest adding an LLVMNormalizeTriple function to the C API (in TargetMachine, I guess) which would wrap Triple::normalize(). Would this be the right way to go...

...ntf); + EXPLICIT_SYMBOL_DEF(__fixdfdi); + EXPLICIT_SYMBOL_DEF(__fixsfdi); + 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(__as...

...nal and begging for testing in mainline CVS. There is one known problem (below), but otherwise it works as well as the static PowerPC backend on the test suite. The known problem is that the JIT seems unable to resolve calls to external functions that start with "__", such as __eprintf, __moddi3, etc. This appears to be something funny in the darwin implementation of dlsym (returning null for symbols that are valid if they start with __). If anyone has any ideas of how to make this work, we would love to hear them. :) -Chris -- http://llvm.org/ http://nondot.org/sabre/

...; to handle this. Maybe I'm not being very clear. I want this replacement to be done at the very last minute (before unreferenced functions are removed, of course). I only want to catch libgcc-ish functions. For example on the x86 (32) a function containing prinf() only needs __divdi3 and __moddi3. I'd like the code generator to do its magic until there is no more magic to do, and then replace any 64 bit divides with the function call, for example. Make sense? -Rich

...ng in mainline CVS. There is one known problem (below), > but otherwise it works as well as the static PowerPC backend on the test > suite. > > The known problem is that the JIT seems unable to resolve calls to > external functions that start with "__", such as __eprintf, __moddi3, etc. > This appears to be something funny in the darwin implementation of dlsym > (returning null for symbols that are valid if they start with __). If > anyone has any ideas of how to make this work, we would love to hear them. > :) > > -Chris -------------- next part --------...

...below), > > > but otherwise it works as well as the static PowerPC backend on the test > > > suite. > > > > > > The known problem is that the JIT seems unable to resolve calls to > > > external functions that start with "__", such as __eprintf, __moddi3, etc. > > > This appears to be something funny in the darwin implementation of dlsym > > > (returning null for symbols that are valid if they start with __). If > > > anyone has any ideas of how to make this work, we would love to hear them. > > > :) > > &...

...march=i386 -falign-functions=0 -falign-jumps=0 \ - -falign-labels=0 + -falign-labels=0 -finline-limit=1000 WARNFLAGS = -W -Wall -Wpointer-arith -Wwrite-strings -Wstrict-prototypes -Winline CFLAGS = -Wp,-MT,$@,-MD,$(dir $@).$(notdir $@).d $(OPTFLAGS) \ --- syslinux-3.07/com32/lib/libgcc/__moddi3.c.gcc4 2004-11-17 02:19:58.000000000 -0500 +++ syslinux-3.07/com32/lib/libgcc/__moddi3.c 2005-03-07 11:26:46.000000000 -0500 @@ -21,7 +21,7 @@ minus ^= 1; } - (void) __udivmoddi4(num, den, &v); + (void) __udivmoddi4(num, den, (uint64_t *)&v); if ( minus ) v = -v; ---...

...t; but otherwise it works as well as the static PowerPC backend on the test > > > > suite. > > > > > > > > The known problem is that the JIT seems unable to resolve calls to > > > > external functions that start with "__", such as __eprintf, __moddi3, etc. > > > > This appears to be something funny in the darwin implementation of dlsym > > > > (returning null for symbols that are valid if they start with __). If > > > > anyone has any ideas of how to make this work, we would love to hear them. > > >...

Chris Lattner wrote: > On Aug 8, 2009, at 8:37 AM, Richard Pennington wrote: > >> Hi, >> >> This patch raises selected instructions to function calls. I've dome >> some preliminary testing and I works: > > Out of curiosity, why do you want this? > I do bitcode linking of a whole program, including the soft-float and other support routines that a

On Aug 8, 2009, at 11:48 AM, Richard Pennington wrote: > Chris Lattner wrote: >> On Aug 8, 2009, at 8:37 AM, Richard Pennington wrote: >> >>> Hi, >>> >>> This patch raises selected instructions to function calls. I've dome >>> some preliminary testing and I works: >> >> Out of curiosity, why do you want this? >> > > I

...still has arbitrary precision integers. The right place to do something like this is in the code generator, which is where it happens. -Chris > > I only want to catch libgcc-ish functions. > > For example on the x86 (32) a function containing prinf() only needs > __divdi3 and __moddi3. > > I'd like the code generator to do its magic until there is no more > magic > to do, and then replace any 64 bit divides with the function call, for > example. > > Make sense? > > -Rich > > _______________________________________________ > LLVM Develope...