similar to: [LLVMdev] MinGW llvm-gcc --enable-stdcall-fixup error

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'm using LLVM-GCC to compile more of the apps I use on my Windows systems and have made mods to Makefile's to accomodate the following issues. Is there anything in the upcoming 2.7 release that make these mods unnecessary? 1) Explicitly passing the linker -Wl,--enable-stdcall-fixup. From an earlier post from Anton I recall that this may not required in 2.7. 2) As binutils windres

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

The problem is a bitcode implementation that has a stdcall function that's used from native code. 1 side has _elements_exception_handler, compiled that would be __elements_exception_handler at 20 due to stdcall. The native bit has the mangled name and the linker can't find it as the bitcode indexes have it without mangling. I'll try to prepare a testcase when I get back in the office.

Clang may be avoiding this problem because it will always emit "\01__elements_exception_handler at 20" as the function name. It probably does that for precisely this reason. On Fri, Mar 30, 2018 at 11:55 AM Carlo Kok via llvm-dev < llvm-dev at lists.llvm.org> wrote: > The problem is a bitcode implementation that has a stdcall function that's > used from native code. 1

I tried the version you used, too. the resulting executable was still broken. I guess the reason is due to fastcall on function pointers, which Clang does not recognize. Consider the following snippet. #include <stdio.h> void __attribute__((fastcall)) f(int i) { printf("%d\n", i); } typedef void (*__attribute__((fastcall)) f_t)(int i); //typedef void

C:\>gem install ''passenger'' ERROR: Error installing passenger: The ''fastthread'' native gem requires installed build tools. Please update your PATH to include build tools or download the DevKit from ''http://rubyinstaller.org/downloads'' and follow the instructions at

Hi! When I set the calling convention of a function to stdcall this has no effect. When I set stdcall to all call instructions then it works. So I wonder what is the use of the calling convention of a function? -Jochen

Hi, I have followed all the instructions to install the ruby on rails as said in the home page ( I think I have done ). But when I run the > rails new tickets after creating new files and sub-directories the following message appears Using rack-ssl (1.3.2) Installing json (1.7.3) Gem::InstallError: The ''json'' native gem requires installed build tools. Please update your

Mixing native and bitcode files should just work, and that happens all the time, as most programs need at least crt.o (which is a precompiled native object file containing startup code). Could you elaborate the issue a bit? It might be a bug in lld. On Fri, Mar 30, 2018 at 3:11 AM Carlo Kok via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Fri, Mar 30, 2018, at 11:23, Carlo Kok

Hello, Arnold. Only quick comments, I'll try to make a full review a little bit later. > 0.)a fast calling convention (maybe use the current > CallingConv::Fast, or create a CallingConv::TailCall) > 1.) lowering of formal arguments > like for example x86_LowerCCCArguments in stdcall mode > we need to make sure that later mentioned CALL_CLOBBERED_REG is >

When having a project that's partially bitcode and partially native code, should lld allow linking a native .o to a bitcode .o? specifically in my case, I've got an stdcall function in bitcode, called by native code, but it can't find the symbol (bitcode has it unmangled, native code with _ and @20)

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

On Wed, Jul 30, 2008 at 03:06:54PM -0700, Julien Lerouge wrote: > On Wed, Jul 30, 2008 at 11:32:18AM -0700, Bill Wendling wrote: > > On Jul 30, 2008, at 11:17 AM, Julien Lerouge wrote: > >> ../../../llvm-gcc4.2-src/gcc/libgcc2.c:2095: error: conflicting types > >> for 'VirtualProtect' > >> > >>

Hi Lars, people. I''ve realized that currently the gem(version 1.6.26) doesn''t work with Ruby 2.0.0 in Windows 32 bits, neither the 64 bits version, I''m talking about the versions listed here: http://rubyinstaller.org/downloads/ . There you can see both versions of Ruby and also the both versions of the DevKit: mingw64-32 and mingw64-64. I''ve tested with both

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