similar to: [LLVMdev] lli/JIT missing libgcc symbols on Mingw32/x86

Hello, I have a bytecode doing 64 bits division and on Mingw32/x86, lli complains it cannot resolve __udivdi3 when running it. Those symbols are all part of libgcc and all present in lli, but they cannot be found by SearchForAddressOfSymbol (not in any DLL). To workaround that, I explicitely define them in Win32/DynamicLibrary.inc if the current target is Mingw32 (patch attached). Anybody had

Hi Thanks for the info, it led to the source of the error I was having. I was using llvm-gcc binaries (built with mingw I guess) to compile a .c file that is my language runtime, llvm-link'ing that with my frontend's .ll, and using an vcpp-built lli to run the resulting bytecode. This caused the special case in X86RegisterInfo::emitPrologue for "main" to try to align the stack

Hello, Scott. > Checking the assembly from llc, the first alloca call is to allocate > local vars in _main. Is this just the state of the code 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

The alloca hook is in lib\System\Win32\DynamicLibrary.inc all the way at the bottom. You'll see a __MING32__ #ifdef around the definition. You just have to implement those methods and it'll work just fine. Jake On 6/24/07, Scott Graham <scott.llvm at h4ck3r.net> wrote: > > Hi > > Thanks for the info, it led to the source of the error I was having. > > I was using

Hello, Julien > First issue is that unittests don't build for MingW, the attached > patch > should fix it. Looks ok for me, however, use __MINGW32__ - this is how it's in all LLVM tree nowadays. > working) and 61242 (first known non working). Are you running bootstrap build? --- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg

Hello, Julien > Any idea why this is happening ? I think I fixed this. Please verify. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

I'm looking forward to your patches and bug reports. I really want to get this going myself. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Anton Korobeynikov Sent: Wednesday, May 10, 2006 1:22 PM To: LLVM Developers Mailing List Subject: [LLVMdev] Successfulyl bootsrapped llvm-gcc4 on mingw32 Hello, Everyone. Today

Hello, Julien > I have this simple IR: That's probably my bug somewhere :) I'm also seeing the difference. Will try to investigate. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Hello, Bill > It may be my lack of understanding, but it appears that having -- > enable-eh set during compilation of llvm-gcc is causing extra files > to be compiled. Oh, no. They are always compiled. > They do. However, it doesn't seem to stop it from failing during > compilation of unwind-dw2.c for libgcc -- it has > "__builtin_eh_return" in it. During

Hello, Everyone. All blackmagic (playing with pwd, etc) in my build description has gone with patched bash (pwd builtin was just hardly disabled). It's not good, I myself prefer modifying libstdc++ configure script to use PWD_CMD environmental variable as main gcc ones. I'm working on this feature. -- With best regards, Anton mailto:asl at math.spbu.ru

2013/3/28 Anton Korobeynikov <asl at math.spbu.ru>: >> How can having an MSVC compatible compiler be to the detriment of clang and >> llvm? No one is trying to break mingw here, merely add support for something > Just to make stuff clear: I just wanted proper naming which will be > non-confusing. Right now we have: > - isTargetWindows() which really means

Hello, llvm-dev. thank you for your interest in my question. Currently, I compiled simple c source code (hello.c) in lunux and windows, and I tried to simple test . first case: hello.bc (compiled with "-emit-llvm" on windows) -> lli.exe(linux). second case: hello.bc (compiled with "-emit-llvm" on linux) -> lli.exe(windows). second case return good result. but First case

Hello, Everyone. Today I've finished digging into llvm-gcc4 in order to build in under mingw32. The most trickiest was to make libstdc++ build, since its configure & makefiles are not so perfect as main gcc ones. There are several problems with inline assemler (in two places at least), but both of them are easily seen. Also, there are some compiler crashes while compiling libiberty (with

Hello, Henrik. You wrote Thursday, May 11, 2006, 5:13:06 AM: HB> Thanks Anton. Nice Job. There was at least one thing I miss in the description: In the step 3 you should unpack runtime libraries from mingw32 distribution into "prefix" (say, w32api and mingw-runtime) before starting configure for GCC. BTW, maybe it will be better just use patched bash (with "pwd" builtin

Hello, Greg. You wrote Sunday, May 14, 2006, 5:21:49 PM: GP> Do I still need to do the "black magic"? In fact, yes. GP> What is this patched version of bash (do you have a patch, where do I get GP> it?) What does "pwd builtin was just hardly disabled" mean? There are some set of built-in commands in bash (they are called "builtins"). For example

Hi Anton, You're already a part of the llvm development team by participating actively on the llvm development list :) If you wish we can put you on: http://llvm.cs.uiuc.edu/Developers.html Great to have you on the team, welcome! We (Jeff, Morten, Paolo, the rest of the team and I) are looking forward to cooperate with you and to push win32 and mingw versions even further to stable and

Ted, > When I try to run lli hello.bc, I get an unsatisfied DLL link error: "This > application has failed to start because pthreadGC.dll was not found." > Hunting around I can't find this DLL anywhere; where should it have come > from? pthreads are required for LLVM. Easy googling ("pthreads mingw32) returns the following place for dlls download:

How can a frontend tell LLVM to put a function argument on stack/register/etc? On Thu, Oct 4, 2012 at 5:08 PM, Anton Korobeynikov <asl at math.spbu.ru> wrote: >> Ah, got it. >> Sounds like we might need to introduce CC_X86_Win32_MSVC_ThisCall then?.. > No, we should not. It should be properly expanded in frontend. > > -- > With best regards, Anton Korobeynikov >

I tried to ask for 32 and that didn't seem to help. MallocInst also seemed to ignore the 16 byte directive. For now, I'm just issuing all my loads as unaligned and that's working ok. Thanks, Chuck. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Evan Cheng Sent: Monday, October 01, 2007 10:35 AM To: asl at

Hello, Paolo. > I hope this is usefull, I'm pretty new to OS X. Well. From your example you have got the only valgrind results: ==28336== 58 bytes in 2 blocks are possibly lost in loss record 70 of 127 ==28336== at 0x4020A92: operator new(unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==28336== by 0x410010B: std::string::_Rep::_S_create(unsigned, unsigned,