similar to: [LLVMdev] LLVM2.2 x64 JIT trouble on VStudio build

Hello, Chuck > I've had a look at the stubs before and I think I'm circumventing them > in the example program since I populate the table and compile the > functions in the order so that things never need to be done lazily, but > I'll look further. Well, anyway stubs are definitely wrong from windows64 and this should be fixed, otherwise funny stuff can happen from time to

Hello, Chuck > Would my life be made fantastically simpler if I were using a different > calling convention for my callback functions on x64 running on Windows? Yes, surely. You can still use 'normal' x86-64 CC if you don't want to call any external functions from code being JITed. Also note a Win64 fixme in the X86CompilationCallback2 function, this can be your case. I think

Hello, Evan > I am not sure if it has been tested on x86-64 Windows. > Anton, do you know? I don't think it was ever written (for vcpp). There is 32-bit stub only. -- WBR, Anton Korobeynikov

Hello, Evan > I think a Win64 version of X86CompilationCallback{2} is still needed. > Also, it's not clear to me how to force a non-Windows CC. It may > require some FE extension to support it? Well, as currently we don't have windows64 support in FE correct (non-windows) CC will be set automatically. -- WBR, Anton Korobeynikov

On Feb 12, 2008, at 5:26 PM, Chuck Rose III wrote: > Hola LLVMers, > > I’m debugging through some strangeness that I’m seeing on X64 on > windows with LLVM2.2. I had to change the code so that it would > engage the x64 target machine on windows builds, but I’ve otherwise > left LLVM 2.2 alone. The basic idea is that I’ve got a function bar > which is compiled by

Hola LLVMers, I'm debugging through some strangeness that I'm seeing on X64 on windows with LLVM2.2. I had to change the code so that it would engage the x64 target machine on windows builds, but I've otherwise left LLVM 2.2 alone. The basic idea is that I've got a function bar which is compiled by VStudio and I'm creating another function foo via LLVM JIT which is going

Hey Evan, At the point of the instructions you suggested I step through, X86ISelLowering has this state: - this 0x00000000005fe728 {VarArgsFrameIndex=-842150451 RegSaveFrameIndex=-842150451 VarArgsGPOffset=3452816845 ...} llvm::X86TargetLowering * const + llvm::TargetLowering {TM={...} TD=0x00000000008edac0

Hello LLVMers, For the windows side of my team's product, I use the VStudio project files included in the LLVM tree (which are VStudio 2k3 files). I just switched over to the SVN sources yesterday and spent some time working with those project files to get things to build cleanly on my system. We use VStudio 2k5, so I have to go through a conversion process which may be the cause of some

Hi Chuck, On Wed, 2007-07-25 at 11:16 -0700, Chuck Rose III wrote: > Hello LLVMers, > > > > For the windows side of my team’s product, I use the VStudio project > files included in the LLVM tree (which are VStudio 2k3 files). I just > switched over to the SVN sources yesterday and spent some time working > with those project files to get things to build cleanly on my

Hola Reid, Cool deal. I think I have all the bugs worked out as I'm building cleanly now in one "build all" pass as opposed to two. I'm going to integrate and test the results with our system. Will the patch process be sufficient for this kind of change (~350K of VStudio XML goo)? Should I request commit access, if at least for the vstudio stuff? Thanks, Chuck.

Hola LLVMers, Our project is cross platform and on Windows we use VStudio 2005. VStudio presents a couple of issues related around it's STL implementation and also it's non-respect for the no-return semantic of abort(). I've fixed it locally, but I'd like to send a patch so I don't have to do this every time I update from the source repository. So.... if I'm

On 31/05/07, Chuck Rose III <cfr at adobe.com> wrote: > Here are the two problem areas: > > RegisterInfoEmitter.cpp > > // Emit the subregister + index mapping function based on the > information > // calculated above. > OS << "unsigned " << ClassName > << "::getSubReg(unsigned RegNo, unsigned Index) const {\n" >

On Thu, 31 May 2007, Chuck Rose III wrote: > Our project is cross platform and on Windows we use VStudio 2005. > VStudio presents a couple of issues related around it's STL > implementation and also it's non-respect for the no-return semantic of > abort(). Ok. We want the source to be portable, so it's goodness to get these fixes into the main tree. > I've fixed

Here are the two problem areas: RegisterInfoEmitter.cpp // Emit the subregister + index mapping function based on the information // calculated above. OS << "unsigned " << ClassName << "::getSubReg(unsigned RegNo, unsigned Index) const {\n" << " switch (RegNo) {\n" << " default: abort(); break;\n"; ...

Nope, it generates an error, not a warning-as-error. (LLVM generates a whole host of warnings when run through the VStudio STL implementation). I misspoke earlier about VStudio ignoring noreturn. I investigated further and found that the implementation of abort in VStudio 2k5 is not tagged noreturn, hence the error. Thanks, Chuck. -----Original Message----- From: llvmdev-bounces at

Hello, Does xen-unstable or Xen xen-3.0.4_1 (or lower) support live migration of winodws based domUs? did anybody tried it ? Regards, Andy _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users

On Mon, 14 Apr 2008, Jon Sargeant wrote: > Ugh, this isn't what I wanted to hear. Passing "complex" differently > than a structure containing two doubles is a bad design, but alas, > calling conventions are beyond our control. How many special cases like > this are there? If "complex" is the only special case, LLVM could There are a huge number of special

> > entirely in the back end. Apart from calling conventions, the front end > > doesn't need to know the specific target, only the data layout and which > > intrinsics the target supports. This approach makes a clean division > > between the front end and back end. > > If you want to map from a C type/calling convetion to LLVM IR, clang is a > good way to

In trying to compile a package with c code using Rtools, -O3 is added by default. This comes from Makeconf? Compiler flags (CFLAGS="-O0 -g" ) set in src/Makevars.win or src/Makevars appear before this. nm pkg.dll reveals no symbols! How can I compile a Windows package with "-O2 -g"? Thanks, RT -- View this message in context:

Hi All, I installed wine in my redhat linux-8.0 machine using wine-20030709-1rh8winehq.i686.rpm and copied wordpad.exe and mfc42u.dll from my win2000 machine to the ~home/.wine/c/windows and system directories and try to run wordpad.exe in wine byr #wine wordpad.exe I am getting error message dialog as The application or DLL can not be loaded on windows95 or 3.1. It takes advantage