search for: __alloca

...roblem. When the jitted routine needs a big stack frame (> 1 page), the system attempts to call __chkstk to probe the stack. This attempt results in assertion in RuntimeDyldELF::resolveX86_64Relocation(), case ELF::R_X86_64_PC32, because the RealOffset does not fit in 32 bits. Same happens with __alloca (when IRBuilder::CreateAlloca appears in a conditional block). Perhaps the issue can be fixed by using indirect call via 64-bit register or replicating service routines inside jitted block. Is it known issue? Repro is available on demand, just let us know in which form you'd like to get it. R...

...can't see a scenario > where we would need those routines in compiler-rt. What's the purpose of __chkstk_ms() then, implemented in compiler-rt? 1. LLVM does NOT create calls to __chkstk_ms(); 2. both the MSVC and the MinGW runtime provide their own __chkstk() as well as their own __alloca() routines. --- llvm.c --- int main(int argc) { int stack[1111]; return _alloca(argc); } --- EOF --- Compiled with "-target i386-mingw" this generates the following code (see <https://godbolt.org/z/yPk4Jo>): _main: # @main push ebp mov ebp, esp mov eax, 4...

...d there). ------------------------------------------------------------------------ .text .align 16 .def _tmp; .scl 3; .type 32; .endef _tmp: pushl %ebp Llabel1: movl %esp, %ebp Llabel2: pushl %ebx pushl %edi pushl %esi subl $4, %esp LBB1_1: # entry2 movl $8, %esi movl %esi, %eax call __alloca movl %esp, %edi movl %esi, %eax call __alloca movl %esp, %ebx movl %esi, %eax call __alloca movl %esp, -16(%ebp) movl %esi, %eax call __alloca movl 8(%ebp), %eax movl %eax, (%edi) movl %eax, (%ebx) movl (%edi), %eax addl %eax, %eax addl %eax, %eax movl %eax, (%esp) <=== shou...

...MisalignedStore; .scl 2; .type 32; .endef .text .globl _MisalignedStore .align 16, 0x90 _MisalignedStore: # @MisalignedStore # BB#0: # %entry pushl %ebp movl %esp, %ebp subl $24, %esp pxor %xmm0, %xmm0 movaps %xmm0, -24(%ebp) movl $8, %eax calll __alloca movl %ebp, %esp popl %ebp ret The code is trivial and useless, but it's a boiled down version of a real program. Am I doing something wrong in that IR? Note that removing the last alloca of %f or the jump to post-block both cause the resulting assembly to be correct. Note also that specify...

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

...lobl _MisalignedStore > .align 16, 0x90 > _MisalignedStore:                       # @MisalignedStore > # BB#0:                                 # %entry > pushl %ebp > movl %esp, %ebp > subl $24, %esp > pxor %xmm0, %xmm0 > movaps %xmm0, -24(%ebp) > movl $8, %eax > calll __alloca > movl %ebp, %esp > popl %ebp > ret > > The code is trivial and useless, but it's a boiled down version of a real > program.  Am I doing something wrong in that IR? It's a known issue that the x86 backend doesn't know how to generate dynamic stack realignment code for...

...%rsp, %rbp diff --git a/test/CodeGen/X86/win_chkstk.ll b/test/CodeGen/X86/win_chkstk.ll index 3f522ea..0c02c1a 100644 --- a/test/CodeGen/X86/win_chkstk.ll +++ b/test/CodeGen/X86/win_chkstk.ll @@ -17,7 +17,7 @@ entry: ; WIN_X32: calll __chkstk ; WIN_X64: callq __chkstk ; MINGW_X32: calll __alloca -; MINGW_X64: callq ___chkstk +; MINGW_X64: callq ___chkstk_ms ; LINUX-NOT: call __chkstk %array4096 = alloca [4096 x i8], align 16 ; <[4096 x i8]*> [#uses=0] ret i32 0 @@ -36,7 +36,7 @@ entry: ; WIN_X64: ret ; MINGW_X64: # BB#0: -; MINGW_X64-NOT: callq _alloca +...

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

Mingw switched abis with the release of gcc 4.7 (http://gcc.gnu.org/gcc-4.7/changes.html). The main change is that now mingw (like msvc) given thiscall calling convention to methods by default. I think the last bug blocking us to support the new abi has just been fixed. The question now is how to switch. The attached patches simply switch llvm and clang to the new ABI. This is similar to what

Hi, I'm trying to do a build and install on Windows 10 with Visual Studio 2015 Community Edition for the X86 and ARM targets, from the current release_40 branch. While compilation completes without error, the INSTALL target fails with the following error: 54> CMake Error at projects/compiler-rt/lib/builtins/cmake_install.cmake:34 (file): 54> file INSTALL cannot find 54>

...+ b/src/libFLAC/md5.c @@ -5,6 +5,19 @@ #include <stdlib.h> /* for malloc() */ #include <string.h> /* for memcpy() */ +#ifdef HAVE_ALLOCA_H +# include <alloca.h> +#elif !defined alloca +# ifdef __GNUC__ +# define alloca __builtin_alloca +# elif defined _AIX +# define alloca __alloca +# elif defined _MSC_VER +# include <malloc.h> +# define alloca _alloca +# endif +#endif + #include "private/md5.h" #include "share/alloc.h" @@ -35,6 +48,7 @@ /* The four core functions - F1 is optimized somewhat */ +#if !defined(HAVE_OPENSSL) /* #define F1(x,...