similar to: [LLVMdev] __fixunsdfdi and etc with Visual Studio JIT?

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

Hello again. I still think that you are wrong. Realignement with and esp,-16 not always changes stack poiner. If esp is already aligned to 16 byte boundary, it will not change! Take a look at following example. Assume esp has value 0x000001000 at start of X86CompilationCallback function. Then execution of it will yield following esp values: 0x000000FFC - after push ebp 0x000000FFC - after mov

Hello again! We have fetched the latest llvm sources from repository and the original problem has went away. Though now we are facing a new problem with interpreter on the following c code: -------------- #include <stdarg.h> #include <stdio.h> void doTheThing(int dummy, ...) { va_list ap; int z; va_start(ap, dummy); while( (z = va_arg(ap, int))!=0) { printf("==

Kristaps Straupe wrote: > Hi! > > We are compiling a very large C project in llvm and trying to execute > it in interpreter. There is a problem with executing the generated > bitcode. The interpreter is under-maintained in general, but this bug in particular is fixed SVN as-of r86428. Are you on a platform that isn't supported by llvm's jit? Nick > We are using

On 02/01/2010 01:13 PM, Kristaps Straupe wrote: > Hello again! > > We have fetched the latest llvm sources from repository and the > original problem has went away. Though now we are facing a new problem > with interpreter on the following c code: > > -------------- > #include <stdarg.h> > #include <stdio.h> > > void doTheThing(int dummy, ...) > {

On 02/03/2010 01:08 PM, Kristaps Straupe wrote: > Hello again. > > I still think that you are wrong. Realignement with and esp,-16 not > always changes stack poiner. If esp is already aligned to 16 byte > boundary, it will not change! Take a look at following example. > Assume esp has value 0x000001000 at start of X86CompilationCallback > function. Then execution of it will

Hi! We are compiling a very large C project in llvm and trying to execute it in interpreter. There is a problem with executing the generated bitcode. We are using lli.exe and llvm-gcc.exe from official 2.6 LLVM release. We have localized the problem to following c code: -------------------- int f(unsigned char x) __attribute__((noinline)); int f(unsigned char x) { return x - 1; } int main()

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

I built the LLVM 2.2 distribution under Visual Studio for x86-64 just fine, but then trying to run my first "hello world" application, found that the JIT compiler was not enabled. I'm completely new to LLVM, so I didn't know exactly where to look to see why the JIT for my platform wasn't being built (is it in the configure steps, or in the C++ code itself?). My educated guess

Hello, Tim > Would adding cases for these assembly blocks that are in Visual Studio > syntax be enough to enable a working x86-64 JIT target under Windows > builds? I can't pretend to understand this codebase, so if there are > more roadblocks stopping 64-bit JIT on Windows targets I'd be > interested to hear... The following things are needed for enabling win64 JIT in 2.2

Microsoft Visual Studio 2012, or 2012 with Update 1, intermittently (90% of the time in my case) crashes when the "Disassembly Window" is opened at the address of JIT code generated by LLVM. This happens when either entering the address into the address bar of the Disassembly Window, or stepping into JIT code that opens the Disassembly Window. Microsoft has acknowledged the crash to

Hello > We are running llvm jit x86 on MS Visual Studio 2005. It seems there > is a bug in asm code in function X86CompilationCallback in file > X86JITInfo.cpp. Current code sets stack pointer to invalid value in > instruction "and   esp,  16". Depending on current stack pointer value > it sometimes overwrites ecx and edx registers with next three lines. How so? The stack

Hi! We are running llvm jit x86 on MS Visual Studio 2005. It seems there is a bug in asm code in function X86CompilationCallback in file X86JITInfo.cpp. Current code sets stack pointer to invalid value in instruction "and esp, 16". Depending on current stack pointer value it sometimes overwrites ecx and edx registers with next three lines. We have fixed this problem by changing this

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

http://bugzilla.mindrot.org/show_bug.cgi?id=552 Summary: broken reference from scp.c Product: Portable OpenSSH Version: 3.6p1 Platform: All OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: dh at

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

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

Chris Lattner wrote: > How do you plan to handle things like arbitrary precision integers, > etc? It seems like you'll end up duplicating a ton of codegen logic > 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

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

Hi, I wonder if anyone else has seen this problem with visual studio 5.0.sp3 We are running NT4.0 sp3 + some updates such as euro etc. The problem is a bit of a surprise as it makes vc++ unusable on a samba share with oplocks on. it is surprising because I have definitely used vc++ in this configuration in the past. It occurs with all versions of samba 1.9.18 from p3 which we use as standard