search for: chkstk

...at 2.0 when > built with vs.net, or is there something that I've managed to > mis-build locally? _alloca is used to probe the stack, if you asks for locals of size more that 4k. This is pretty ugly, but the names of this functions differs for mingw32 variant (_alloca) and something like chkstk (vcpp). For mingw32 it's exported in libgcc, dunno about vcpp (probably from some runtime libraries). Since there is no dynamic linking on windows, there is special hook to resolve _alloca call at runtime. Surely, this won't be applicable for lli built by vcpp. Probably, you'll have e...

"Friedman, Eli" <efriedma at codeaurora.org> wrote: > On 11/30/2018 8:31 AM, Stefan Kanthak via llvm-dev wrote: >> Hi @ll, >> >> compiler-rt implements (for example) the MSVC (really Windows) >> specific routines compiler-rt/lib/builtins/i386/chkstk.S and >> compiler-rt/lib/builtins/x86_64/chkstk.S as __chkstk_ms() >> See <http://msdn.microsoft.com/en-us/library/ms648426.aspx> >> >> Is there any special reason why compiler-rt doesn't implement >> other MSVC specific functions (alias builtins or "com...

Hi @ll, compiler-rt implements (for example) the MSVC (really Windows) specific routines compiler-rt/lib/builtins/i386/chkstk.S and compiler-rt/lib/builtins/x86_64/chkstk.S as __chkstk_ms() See <http://msdn.microsoft.com/en-us/library/ms648426.aspx> Is there any special reason why compiler-rt doesn't implement other MSVC specific functions (alias builtins or "compiler intrinsics") for which clang/LLVM...

...with vs.net, or is there something that I've managed to > > mis-build locally? > > _alloca is used to probe the stack, if you asks for locals of size more > that 4k. This is pretty ugly, but the names of this functions differs > for mingw32 variant (_alloca) and something like chkstk (vcpp). For > mingw32 it's exported in libgcc, dunno about vcpp (probably from some > runtime libraries). > > Since there is no dynamic linking on windows, there is special hook to > resolve _alloca call at runtime. Surely, this won't be applicable for > lli built by vcpp....

...something that I've managed to > > > mis-build locally? > > > > _alloca is used to probe the stack, if you asks for locals of size more > > that 4k. This is pretty ugly, but the names of this functions differs > > for mingw32 variant (_alloca) and something like chkstk (vcpp). For > > mingw32 it's exported in libgcc, dunno about vcpp (probably from some > > runtime libraries). > > > > Since there is no dynamic linking on windows, there is special hook to > > resolve _alloca call at runtime. Surely, this won't be applicable fo...

Hi All, we have an issue with our LLVM-based JIT compiler - executing the compiled code corrupts memory (and subsequently crashes) if we alloca more than 4k of variables (more than 511 8-byte ints). The same code works on Windows 7 (32 and 64 bit), Linux, MacOS. We compile LLVM and our program with Microsoft's Visual Studio 2010. Both debug and release builds are affected. The variables

We tested on 3.4.2 and 3.5.1. Later versions are slightly problematic to test since they don't compile with VS2010. Do you happen to know if it's fixed in one of the released versions, or if there is a workaround (chkstk?) or a bug report online? Thanks! Eph On 30.06.2015 12:58, Nicholas Chapman wrote: > It's a known issue. I believe it's fixed in trunk however. > What LLVM version are you using? > > Nick > > On 30/06/2015 10:21, Ephrim Khong wrote: >> Hi All, >> >&g...

...it binary for better performance or whatnot, you'll have > to build from source for now. > > Thats not gonna work though: clang version 3.5.0 (213584) Target: i686-pc-windows-gnu Thread model: posix C:\Users\ismail\Desktop>clang -target x86_64-pc-windows-msvc -m64 nic.c libcmt.lib(chkstk.obj) : fatal error LNK1112: module machine type 'X86' conflicts with target machi e type 'x64' clang.exe: error: linker command failed with exit code 1112 (use -v to see invocation) Seems to be libpath is not properly set for 64bit case. -------------- next part -------------- An H...

I am trying to find Clang binaries to download for the Windows x86-64 target and have not been successful. Do any such binaries exist? Thank you, Simon Koeman -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140725/09d99203/attachment.html>

Bug is reported with test cases. see http://llvm.org/bugs/show_bug.cgi?id=15124 . Thanks, -Peng On Wed, Jan 30, 2013 at 12:14 PM, Anton Korobeynikov < anton at korobeynikov.info> wrote: > > Has anyone seen this problem before? and is there any fix or work around > > for that? > Please provide a testcase and fill LLVM problem report into bugzilla. > > Thanks! >

...more > deeply (or if someone points me at it...). It's in lib/System/Win32/DynamicLibrary.inc I'd suggest you to check, whether vcpp stack probing routine and _alloca has the same signature. If yes - we can easily fix the code emission. Otherwise we'll need extra information about chkstk. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

On Windows, the LLVM JIT runner looks for the '_chkstk' symbol by enumerating all of the loaded DLLs. On Win8, NTDLL.DLL (where _chkstk is defined) is found in a location that is more than 32bits bytes away from the jitted code. Marina's patch changes the code that generates a call to '_chkstk' from PCREL32 (which uses a 32bit offset)...

Hi, We are seeing sporadic crashes since we migrated to MCJIT on Win64. The same tests pass without issues on Mac64 and Linux64. The issue is this assertion failure in RuntimeDyldELF.c: RealOffset <= INT32_MAX && RealOffset >= INT32_MIN I haven't managed to successfully catch the failure in Visual to try and debug it. Any tips on how to make progress? Oh, and we're on

...ell me what LLVM code in ExecutionEngine is responsible for allocating and protecting memory for generated native functions? > > Best regards, > Victor Milovanov. > > 2012/3/2 NAKAMURA Takumi <geek4civic at gmail.com>: >> Viktor, could you try my patch? I guess they are __chkstk. >> >> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120220/1 >> 37577.html >> >> ...Takumi > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu > http://li...

I started to implement inlining of the stack probe function based on Microsoft's inlined stack probes in https://github.com/Microsoft/llvm/tree/MS. Do we know why the stack pointer cannot be updated in a loop (which results in ideal code)? I noticed that was commented in Microsoft's code. I suspect this is due to debug or unwinding information, since it is allowed on Windows x86-32. I

I would think that the R_X86_64_PC32 relocation type should never be generated with large code model since large code model, by definition, makes no assumptions about the size or address of sections. The use of win32-elf might throw a wrinkle into this, since that is a code path that probably isn't exercised much outside of MCJIT use. That said, when this assertion fails it is usually

...dcfg.test lld :: COFF/loadcfg32.test lld :: COFF/locally-imported-arm64.test lld :: COFF/locally-imported-warn-multiple.s lld :: COFF/locally-imported.test lld :: COFF/locally-imported32.test lld :: COFF/long-section-name.test lld :: COFF/lto-cache.ll lld :: COFF/lto-chkstk.ll lld :: COFF/lto-comdat.ll lld :: COFF/lto-debug-pass-arguments.ll lld :: COFF/lto-lazy-reference.ll lld :: COFF/lto-linker-opts.ll lld :: COFF/lto-new-symbol.ll lld :: COFF/lto-opt-level.ll lld :: COFF/lto-parallel.ll lld :: COFF/lto-reloc-model.ll lld :: COFF...

On Thu, Feb 8, 2018 at 10:43 PM, Dimitry Andric <dimitry at andric.com> wrote: > On 7 Feb 2018, at 21:51, Hans Wennborg via Release-testers <release-testers at lists.llvm.org> wrote: >> >> There's been a lot of merges since rc1, and hopefully the tests are in >> a better state now. >> >> 6.0.0-rc2 was just tagged, after r324506. >> >>