similar to: [LLVMdev] [LLVMbugs] Compiling to Win32

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

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, 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

> Anyone seeing this failure? > > FAIL: /Volumes/Gir/devel/llvm/llvm.src/test/CodeGen/Generic/2007-04-14-EHSelectorCrash.ll > for PR1326 Seems it was due to my changes. Investigating. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Hello, Everyone. Now I have some spare time and I've decided to build LLVM on Mingw. I've grab the latest 1.7 release (not CVS snapshot). Here are some issues fixed during the build. Now I'm preparing gcc build. So, I think, there will some other "parts" 1. Prerequisites 1.1 GCC 3.4.5 from mingw.org site. $ gcc --version gcc.exe (GCC) 3.4.5 (mingw special) Copyright (C)

Hello! I have previously posted this question on llvm-bugs, but I was redirected and asked to post to llvmdev, so I'm resending this message to this mailing list. I am interested in LLVM, particularly for the implementation of a programming language, and have been looking at the LLVM documentation recently. However, I was wondering what exactly do these two lines, extracted from the

I need to distribute rsync (useable for both client and --daemon) on Win32. Distributing cygwin1.dll is, well you know, a bad idea. I took a shot at building under MingW but ran into an ugly looking error: > checking for socklen_t... no > checking for socklen_t equivalent... configure: error: Cannot find a > type to use in place of socklen_t I will pay $50 for a MingW build of latest

Hi Evan > It looks fine to me. Anton, does it look ok to you? This looks ok for me modulo win64+vcpp issues, which I mentioned in the PR (external .asm files). The anonymous namespace thing should be guarded by define (either _M_AMD64 or X86_64_JIT && _MSC_VER, I'd prefer the latter). -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint

Hello, Scott. > Is that generally dangerous, or should it be OK? Well, in general, it's dangerous, because you should probe the stack on windows, if you'll allocate more than 4k. This is needed to let guard pages be allocated in proper order. So, you can see random crashes here and there now :) For example: try to allocate big array (>4k of size) and touch its last element (this

Hello, Chuck. > "Error, Program used external function _alloca which could not be resolved!" I think the problem is the same. But... Cygwin is handled separately, because it's really more unix-like, that e.g. mingw32. Even more, it uses "unix" variant of libSystem. Probably you have to introduce the same hook (as for mingw32 / vcpp) there. -- With best regards, Anton

Anton, I didn't know that EQUIVALENCE is the only unsupported major Fortran feature, as this bug says. Can you give me an update on the status of the Fortran front-end and what the near-term goals are? I am getting more requests from academics doing HPC compilers and it would be useful to know where Fortran support stands. Other llvmdev'ers may be interested too. Thanks,

Vikram, > I didn't know that EQUIVALENCE is the only unsupported major Fortran > feature, as this bug says. Can you give me an update on the status of > the Fortran front-end and what the near-term goals are? Ok. I was going to post something soon after 2.2 release, but let's do it now. LLVM 2.2 will contain (as a part of llvm-gcc 4.2) a port of gfortran compiler to the LLVM

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

Yes, you are right. During my testings, I tried the llvm produced .S files with the gcc frontend and it compiled and linked them to the final executable. The problem is with the gcc and binutils licence. This is GPL and while this is ok for open source or for academic purposes, it can't be used on commercial projects. In fact one of the strong points of llvm (and clang) is its BSD like

On May 24, 2006, at 5:03 AM, Anton Korobeynikov wrote: > Hello, Ashwin. > > You wrote Wednesday, May 24, 2006, 11:25:11 AM: > > AC> "Pass::getClassPassInfo<PassClass>() "Pass class not > AC> registered!"" failed: file > AC> "/cygdrive/c/llvm/llvm/include/llvm/PassAnalysisSupport.h", > line 76 > AC> Aborted > Same

> There's also then entire GNU toolchain, through MinGW and/or Cygwin. Which works perfectly right now without any extra tweaking :) -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Razvan, You're somewhat misinterpreting the GPL license. Using binutils as a dependency of LLVM does not require that they be linked into any distributable that might contain proprietary code. They can be shipped as separate, purely-GPL'd executables that are called via the command line, thereby avoiding the whole "infection" problem. This is, for instance, how

Hi Anton, Is the patch going to be uploaded to the CVS source? Ashwin On 5/24/06, Evan Cheng <evan.cheng at apple.com> wrote: > > > On May 24, 2006, at 5:03 AM, Anton Korobeynikov wrote: > > > Hello, Ashwin. > > > > You wrote Wednesday, May 24, 2006, 11:25:11 AM: > > > > AC> "Pass::getClassPassInfo<PassClass>() "Pass class

Hello, Ashwin. You wrote Wednesday, May 24, 2006, 11:25:11 AM: AC> "Pass::getClassPassInfo<PassClass>() "Pass class not AC> registered!"" failed: file AC> "/cygdrive/c/llvm/llvm/include/llvm/PassAnalysisSupport.h", line 76 AC> Aborted Same for me. AC> Wihtout the -march specified (using native x86 assembly) it does AC> convert it into

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