similar to: [LLVMdev] LLVM code emittion and C++ compiler compatibily

Hello! I have a question how about JIT-ed code and the C++ compiler compatibily. My project (www.baadengine.org) will use llvm and we will provide integration of JIT-ed code directly into C++ code. This means that C++ code can call JIT code just like any other code and JIT-ed code can call C++ code. We will compile to your bytecode from our BSF format. The question is if it is possible this

On Mon, 6 Nov 2006, [ISO-8859-2] Žiga Osolin wrote: > The other thing are the return types. I don't know (it is probably even > not documented) how VC++ returns smart pointer (boost::smart_ptr), > or any other type (other basics types, such as int, float, ... are > probably returned into EAX as with GCC). Once again, we may > need specific return values per arhitecture. It is

> On Mon, 6 Nov 2006, [ISO-8859-2] Žiga Osolin wrote: >> The other thing are the return types. I don't know (it is probably even >> not documented) how VC++ returns smart pointer (boost::smart_ptr), >> or any other type (other basics types, such as int, float, ... are >> probably returned into EAX as with GCC). Once again, we may >> need specific return values

On Mon, 6 Nov 2006, [ISO-8859-2] Žiga Osolin wrote: > The problem is this is not possible, because what I would compile to JIT > are actual classes. The integration of C++ and JIT code is very > important; for example we would create our own vtbls with JIT-ed code > addresses as the function call target. Ok. Realize that this ties you to a specific compiler version though. >

Anton Korobeynikov pravi: > Hello, Ziga. > > >> VCPP throws a warning that class is previously declared as struct. >> Either it must be struct everywhere or class everywhere. >> Declaration uses struct, while the definition uses class. >> > Nice! However it will be better to do the opposite: have it struct > everywhere. I'll fix this. >

I wanted to mention that I'm planning to start writing and sending out patches for this. Naming the attribute 'alloca' was really confusing, so I'd like to change it to 'inalloca', which follows the preposition pattern of inreg and byval. After discussion, we decided it was silly to add stackbase uses to alloca instructions. They should stay simple. Instead, we'll

Hi Reid, On 25/07/13 23:38, Reid Kleckner wrote: > Hi LLVM folks, > > To properly implement pass-by-value in the Microsoft C++ ABI, we need to be able > to take the address of an outgoing call argument slot. This is > http://llvm.org/PR5064 . > > Problem > ------- > > On Windows, C structs are pushed right onto the stack in line with the other > arguments. In

Initial Announcement: Package rdyncall released on CRAN. (Version 0.7.3) The package was presented at the Use!R 2009 with the title 'An improved Foreign Function Interface for R' and is now available on CRAN and considered stable for a large range of R platforms. The package provides a cross-platform framework for dynamic binding of C libraries using a flexible Foreign Function

Initial Announcement: Package rdyncall released on CRAN. (Version 0.7.3) The package was presented at the Use!R 2009 with the title 'An improved Foreign Function Interface for R' and is now available on CRAN and considered stable for a large range of R platforms. The package provides a cross-platform framework for dynamic binding of C libraries using a flexible Foreign Function

How do you handle this during codegen? One problem is avoid stack changes (like spills). Another is coordinating things that are using allocas and those that are not but end up in the stack. Consider void foo(int arg1, int arg2, int arg3, ....CXXTypeWithCopyConstructor argn, int argp1...) You will need an alloca for argn, but the ABI also requires it to be next to the plain integers that

I'm trying to understand the LLVM calling conventions. Coming from a Windows C++ background, I'm familiar with three calling conventions: cdecl, stdcall, and fastcall. It looks like cdecl corresponds to ccc in LLVM, but I'm not sure about the other two. Best Regards, Jon

Hi LLVM folks, To properly implement pass-by-value in the Microsoft C++ ABI, we need to be able to take the address of an outgoing call argument slot. This is http://llvm.org/PR5064 . Problem ------- On Windows, C structs are pushed right onto the stack in line with the other arguments. In LLVM, we use byval to model this, and it works for C structs. However, C++ records are also passed this

The Wine development release 4.15 is now available. What's new in this release (see below for details): - Initial implementation of the HTTP service. - Stack unwinding support on ARM64. - Better multi-monitor support on macOS. - RichEdit control optimizations. - Various bug fixes. The source is available from the following locations:

Hi, I am trying to implement on a Win7 box the showArgs example of section 5.10.2 "Calling .External" of the R extension manual. I am using interchangeably gcc (RTools) and Visual C++ (via Makefile.win) to build a package. I get a couple of runtime oddities when the dll compiled with Visual C++. I'd value comments, observations and tips from interested readers. I tried my best to

Hi, I'm trying to load a dynamic link library and it seems to work (is.loaded -> TRUE). When I run the function, which calls the .Fortran subroutine, R crashes! I'v tried the same in S-Plus 2000 and it worked. Therefore I suppose that the dll has been compiled with the stdcall calling convention (and not cdecl). But the problem is that I don't have access to the source code,

I think we need to relax the test cases. MSVC usually prints the calling convention, and it's often useful information. Maybe we can make the diagnostic text smaller by using the __thiscall, __cdecl, __stdcall, etc keywords when printing types with LangOpts.MicrosoftExt, but it will require moving the attribute from after the identifier to before, which is exciting. On Tue, Dec 10, 2013 at

On Tue, Dec 10, 2013 at 4:39 PM, Reid Kleckner <rnk at google.com> wrote: > I think we need to relax the test cases. MSVC usually prints the calling > convention, and it's often useful information. I was going to argue that MSVC doesn't print them, but then I tried, and you're right - it does :) I'll start relaxing the tests then. > Maybe we can make the

Chris Lattner pravi: > On Tue, 21 Nov 2006, [ISO-8859-2] Žiga Osolin wrote: >> I was going through documentation and source lately, and I decided >> how to >> make llvm bytecode more compatible to C++: >> 1) thiscall sould be introduced, which would take N arguments and the >> first argument would always be the C++ "this" argument. This would >>

I was going through documentation and source lately, and I decided how to make llvm bytecode more compatible to C++: 1) thiscall sould be introduced, which would take N arguments and the first argument would always be the C++ "this" argument. This would abstract llvm compiler dependant C++ code emittion. 2) the ret instruction should be able to return structs (as Chris has already

Hello > I don't know. I feel reluctant to generate different IRs for Win32 and > for Win64. Unfortunately, you should. Think about differences and between _Complex type and struct {double, double}. >From LLVM's point of view these are same types, however many ABIs have special rules for passing / returning _Complex, this is possible to handle in frontend only. > Since the C