similar to: [LLVMdev] thiscall on MSVC

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There doesn't appear to be a calling convention matching "thiscall"... on gcc targets, the standard calling convention is fine (just pass "this" as the first parameter), but with MSVC this won't work because it passes "this" in %ECX. Is there a workaround for this? Or how hard would it be to add a separate

Dear All, I was wondering if there are any plans to support MSVC thiscall calling convention (where 'this' is passed in ECX and the callee cleans the stack). If not how difficult do you think is implementing it. Thanks, Victor -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Tue, Oct 2, 2012 at 8:44 PM, Anton Korobeynikov <asl at math.spbu.ru> wrote: >>>> b) Should I be altering CC_X86_32_ThisCall >>>> OR should I introduce CC_X86_Win32_ThisCall instead? >>>> [Answer not clear to me - is there any platform besides Windows >>>> that uses thiscall?] >>> no >> Can you please clarify which

Hello Aaron, Anton, LLVM-dev, While working on http://llvm.org/PR13676#c6 I found out that whenever I compile code with class methods returning structures it get generated incompatible with MSVC. Looking at lib/Target/X86/X86CallingConv.td, I found out that CC_X86_32_ThisCall maps SRet to EAX but in fact it should push the address of the return temp on stack. The following patch fixes the issue

On Tue, Oct 2, 2012 at 7:03 PM, Anton Korobeynikov <asl at math.spbu.ru> wrote: > Hello Timur, > >> I'd like to ask for advice: >> a) Is it OK to change the SRet/ThisCall behaviour on non-Windows platforms? >> [I suppose no] > no > >> >> b) Should I be altering CC_X86_32_ThisCall >> OR should I introduce CC_X86_Win32_ThisCall

Hi all, A few things. Firstly, I've got a working implementation of the X86ThisCall calling convention, but I'm unsure how to go about submitting it. (I'm not really sure how to go about creating patch files etc, but would like to contribute to the project). Also, I'm using MS Visual C++ Express, and there are a few things that stop llvm1.9 (and the current CVS release) from

On Tue, Oct 2, 2012 at 11:02 AM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > On Tue, Oct 2, 2012 at 8:28 PM, David Blaikie <dblaikie at gmail.com> wrote: >> On Tue, Oct 2, 2012 at 8:54 AM, Timur Iskhodzhanov <timurrrr at google.com> wrote: >>> [+cfe-dev as this does seem like both LLVM+Clang issue] >>> [Sorry for an incomplete e-mail context,

[+cfe-dev as this does seem like both LLVM+Clang issue] [Sorry for an incomplete e-mail context, please see http://llvm.org/PR13676#c6 if you're interested] I've read these bugs and now I'm even more confused than I was before :) What do you think about the following approach: a) I'll create test cases for the major issues I've observed so far These test cases will check

2013/3/28 Anton Korobeynikov <asl at math.spbu.ru>: >> How can having an MSVC compatible compiler be to the detriment of clang and >> llvm? No one is trying to break mingw here, merely add support for something > Just to make stuff clear: I just wanted proper naming which will be > non-confusing. Right now we have: > - isTargetWindows() which really means

Hello, David. > A few things. > Firstly, I've got a working implementation of the X86ThisCall calling > convention, but I'm unsure how to go about submitting it. > (I'm not really sure how to go about creating patch files etc, but > would like to contribute to the project). I suppose, you've changed X86ISelLowering.cpp, X86*AsmPrinter.cpp, CallingConv.h. Right?

On Tue, Dec 10, 2013 at 5:08 PM, Hans Wennborg <hans at chromium.org> wrote: > 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, >

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

Hi all, I am trying to generate LLVM IR that calls an external C++ function returning a structure by copy: vec3 vec3::Cross(const vec3& iV) const; Here is the LLVM IR that I am generating for win32 ABI, which says that the first parameter should be a pointer to the return value: %vec3 = type <{ float, float, float }> define void @CPP_Return_Struct(%vec3* %v1, %vec3* %v2) inlinehint

Hello Timur, > I'd like to ask for advice: > a) Is it OK to change the SRet/ThisCall behaviour on non-Windows platforms? > [I suppose no] no > > b) Should I be altering CC_X86_32_ThisCall > OR should I introduce CC_X86_Win32_ThisCall instead? > [Answer not clear to me - is there any platform besides Windows > that uses thiscall?] no It seems for me

On Tue, Oct 2, 2012 at 8:54 AM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > [+cfe-dev as this does seem like both LLVM+Clang issue] > [Sorry for an incomplete e-mail context, please see > http://llvm.org/PR13676#c6 if you're interested] > > I've read these bugs and now I'm even more confused than I was before :) > > What do you think about the

On Tue, Oct 2, 2012 at 8:28 PM, David Blaikie <dblaikie at gmail.com> wrote: > On Tue, Oct 2, 2012 at 8:54 AM, Timur Iskhodzhanov <timurrrr at google.com> wrote: >> [+cfe-dev as this does seem like both LLVM+Clang issue] >> [Sorry for an incomplete e-mail context, please see >> http://llvm.org/PR13676#c6 if you're interested] >> >> I've read

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

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 Thu, Mar 28, 2013 at 1:46 PM, Anton Korobeynikov <asl at math.spbu.ru> wrote: >> Sounds fine to me. I just wanted some convenient and consistent naming. >> I think it conflicts a bit with the triples (-win32 currently means >> msvc I think), > Right. But this is again a historical (and LLVM-specific) artifact, > because I doubt anyone uses such triplet outside to