similar to: cdecl and stdcall

This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C39C9F.B5DABBD0 Content-Type: text/plain; charset="iso-8859-1" # Your mailer is set to "none" (default on Windows), # hence we cannot send the bug report directly from R. # Please copy the bug report (after finishing

Hello, The procedure for creating an import library (Rdll.lib) that is documented in gnuwin32/README.packages works fine using the i386 architecture, but it doesn't seem to work under x64. Specifically, the procedure is: pexports R.dll > R.exp lib /def:R.exp /out:Rdll.lib /machine:X86 R.dll There are two issues under x64: 1. Older version of pexports crash when applied to an x64 R.dll.

Hello all, I am a beginner of LLVM and I want to add a new backend into LLVM. The calling convention of the target I ported is CDECL. I am wondering to know whether there is already CDECL calling convention implemented in LLVM?? Which CallingConv.td file should I copy and modify for my target?? thanks a lot Mitnick -------------- next part -------------- An HTML attachment was scrubbed... URL:

When attempting to compile this simple testing tool http://github.com/oneclick/rubyinstaller/blob/fake/resources/tools/fakeruby.c I get the following: C:\Users\Jon\Documents\CDev\sandbox>llvm-gcc -Wall -o fakeruby.exe fakeruby.c Warning: resolving _GetModuleHandleA by linking to _GetModuleHandleA at 4 Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable

Hi, I'm trying to run the following module in lli on LLVM 2.6, Windows/MSVS 2008, 32 bits memory model: --- declare x86_stdcallcc i8* @GetStdHandle(i32) define i32 @main() { %handle = call i8* @GetStdHandle(i32 -11) ret i32 0 } --- (This small modules that just retrieve the handle to stdout using WIN32 API). I'm converting it to bytecode using: llvm-as.exe -f

Hello > Is the x86_stdcallcc call convention actually supported? I found it by > digging into LLVM sources Yes. It's fully supported. > Is my initial LLVM-IR correct for invoking WIN32 API function? No. You forgot to put calling convention on the call itself. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

2009/12/9 Anton Korobeynikov <anton at korobeynikov.info> > Hello > > Is my initial LLVM-IR correct for invoking WIN32 API function? > No. You forgot to put calling convention on the call itself. > Thanks, this work great! I naively though it would pick up the call convention from the declaration as there was no error like we have when the wrong number of parameters is

Hello > I naively though it would pick up the call convention from the declaration > as there was no error like we have when the wrong number of parameters is > used. This is not an error, you're just invoking undefined behaviour. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

I too have stumbled over this. Wouldn't it be a good idea to add a check for this to the function verifier pass? Hans Anton Korobeynikov wrote: > Hello > >> I naively though it would pick up the call convention from the declaration >> as there was no error like we have when the wrong number of parameters is >> used. > This is not an error, you're just

Hans Wennborg wrote: > I too have stumbled over this. > > Wouldn't it be a good idea to add a check for this to the function > verifier pass? No. This is a FAQ: http://llvm.org/docs/FAQ.html#callconvwrong Nick > > > Hans > > Anton Korobeynikov wrote: >> Hello >> >>> I naively though it would pick up the call convention from the declaration

On Thu, Dec 10, 2009 at 12:21 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > Hans Wennborg wrote: >> I too have stumbled over this. >> >> Wouldn't it be a good idea to add a check for this to the function >> verifier pass? > > No. This is a FAQ: http://llvm.org/docs/FAQ.html#callconvwrong IMO you could move the cc to the type and still replace mismatched

>From the R-2.6.0/doc/README.packages it says: Using Visual C++ ================ You may if you prefer use Visual C++ to make the DLLs (unless they use Fortran source!). The notes here were tested with VC++6. First build the import library Rdll.lib by make R.exp ... In the installation (R-2.6.0-win32.exe) there is no Makefile with an R.exp target that I could find and I get

On Wed, 9 Feb 2005, Chris Lattner wrote: > On Wed, 9 Feb 2005, Henrik Bach wrote: > >> Here is my first try to document, how to build the llvm suite for MinGW. > > The GettingStarted patch looks fine to me, and I've applied it here: > http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050207/023986.html > > The other patch does not look ok. In particular,

>From: Jeff Cohen <jeffc at jolt-lang.org> >Date: Tue, 28 Sep 2004 13:05:16 -0700 > >They are part of the Platform SDK from Microsoft, part of Visual Studio. >They correspond to Window system DLLs dbghelp.dll and psapi.dll in Arrrggg, I forget this relation... >\winnt\system32. If you do not have these libs, then you are out of >luck. Mingw should have provided them

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

I started a brand new session in R 2.10.1 (on Windows). If it matters, I am running the community edition of MySQL 5.0.67, and it is all running fine. I am just beginning to examine the process of getting timer series data from one table in MySQL, computing moving averages and computing a selection of estimates based on relations among moving averages of different variates, and storing all the

>From: Chris Lattner Date: Wed, 9 Feb 2005 15:11:44 -0600 (CST) > >On Wed, 9 Feb 2005, Chris Lattner wrote: > >>On Wed, 9 Feb 2005, Henrik Bach wrote: >> >>>Here is my first try to document, how to build the llvm suite for MinGW. >> >>The GettingStarted patch looks fine to me, and I've applied it here:

Hi all, I need the power of R from within some of my Python programs... I use debian linux (woody) at home and windows XP at work (the latter is where I need to get things done!) This are my packages: R 1.8.0 Python 2.3 RSPython 0.5-3 This is what I've done: (1) Since the Windows Binary of RSPython is compiled against Python 2.2 I downloaded the tarball (2) Followed the instructions in

Hi, I am having problems calling a fortran routine from within R. When the routine is called, R exits with an application error: "The instruction at 0x004a8b7d referenced memory at 0x200000015. The memory could not be written". The R code used to call the routine is: .Fortran("GTEST",a=as.integer(1),b=as.integer(3),c=as.integer(-10),d=as.inte ger(0),e=as.integer(0)) The

On Wed, 9 Feb 2005, Henrik Bach wrote: > Here is my first try to document, how to build the llvm suite for MinGW. The GettingStarted patch looks fine to me, and I've applied it here: http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050207/023986.html The other patch does not look ok. In particular, it would be much better to submit patches to make MinGW work as much like