search for: thiscal

...", "gaussian"), xlab = deparse(substitute(x)), ylab = deparse(substitute(y)), ylim = range(y, prediction$y), evaluation = 50, ...) { if (inherits(x, "formula")) { if (length(x) < 3) stop("need response in formula") thiscall <- match.call() thiscall$x <- x[[3]] thiscall$y <- x[[2]] return(invisible(eval(thiscall, sys.parent()))) } ################## plot(x, y, xlab = xlab, ylab = ylab, ...) i<-complete.cases(x,y) x<-x[i] y<-y[i] ################## predicti...

...ion, 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. Attached is a patch that fixes all the test failures I saw due to printing out the thiscall attribute on types. Do we want to land this now, or wait until the thiscall switch is actually flipped for MinGW? - Hans >> On Tue, Dec 10, 2013 at 4:20 PM, Hans Wennborg <hans at chromium.org> wrote: >>> >>> On Tue, Dec 10, 2013 at 3:57 PM, Reid Kleckner <rnk...

...gt; cq function (...) { as.character(sapply(as.list(match.call(expand.dots = TRUE))[-1], as.character)) } <bytecode: 0x7fca88443f78> <environment: namespace:mvbutils> I tried to write > sympyq function(...) { arg <- as.character(match.call(expand.dots=TRUE)[-1]) thiscall <- as.call(list(as.name("sympy"), arg)) print( thiscall ) # for debugging eval(thiscall, parent.frame() ) } Some examples: (After doing Var("x,y,z") ) > sympyq(4+4) sympy("4 + 4") [1] "8" > sympyq(3*x+4*y+89*z-6*x) sympy("3 * x + 4 *...

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 Windows: --------------------------------- Index: lib/Target/X86/X86CallingConv.td =================================================================== --- lib/Target/X86/X86...

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: <http://lists.llvm.org/pipermail/llvm-dev/attachments...

-----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 "thiscall" conven...

Hello Benjamin, > Is there a workaround for this? Or how hard would it be to add a separate > "thiscall" convention which maps to "ccc" on GCC-like targets and the custom > MSVC target on MSVC-x86? I don't think it's good idea to have calling convention to be lowered differently depending on subtarget: everything should be modelled explicitly. It isn't hard to add thi...

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

...ys 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 > alignstack(16) { > ENTRY: >  %"@0" = alloca %vec3, align 4 >  call x86_thiscallcc void @vec3_Cross(%vec3* sret %"@0", %vec3* %v1, %vec3* > %v2) >  ret void > } > > declare x86_thiscallcc void @vec3_Cross(%vec3* sret, %vec3*, %vec3*) align 2 > > It seems that the code generated by the JIT takes the first parameter for > the this value because...

...t 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 alignstack(16) { ENTRY: %"@0" = alloca %vec3, align 4 call x86_thiscallcc void @vec3_Cross(%vec3* sret %"@0", %vec3* %v1, %vec3* %v2) ret void } declare x86_thiscallcc void @vec3_Cross(%vec3* sret, %vec3*, %vec3*) align 2 It seems that the code generated by the JIT takes the first parameter for the this value because of the X86_thiscall calling conventio...

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 relea...

...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 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. This seems like a nice thing to do, but I'll get the tests going with what we've got for now....

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? Just s...

The build problems with VC++ 7.1 have been fixed. If VC++ 8.0 still has problems, please mail me the build log.

...is correct. > What's more stranger: I casted the address of the virtual function "down" to a normal function, but with the same return value. When I call this construct, then the return value is correct! This doesn’t sound like an ELF issue. On Windows, virtual functions use the ‘thiscall’ calling convention, where the *callee* cleans up the stack. In the standard Windows x86 calling convention, ecx is the first integer or pointer argument. In the thiscall calling convention, it is the `this` pointer, so if you are creating a function with the normal calling convention and callin...

...rrr at google.com> wrote: >>>> 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 instead...

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 question you've answered here? > To...

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 instead? >> [Answer not clear to me - is there any platform besides Windows >> that...

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...

> Attached is a patch that fixes all the test failures I saw due to > printing out the thiscall attribute on types. > > Do we want to land this now, or wait until the thiscall switch is > actually flipped for MinGW? Maybe combining the patches would be the best? It is funny, I had never tried check-all on mingw. I just did and found some codegen errors, mostly when we look for ca...