similar to: [LLVMdev] Compiling As Obj-C or Obj-C++ On Windows

We inject a typedef for size_t here: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/Sema.cpp?revision=218230&view=markup#l206 The typedef type is determined by calling getSizeType(). SizeType is (relevantly) calculated in two places: X86_64 http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?revision=218666&view=markup#l3512 X86_32

I'm trying to compile some C++ code on Windows that contains blocks. The compiler gives me the error that the blocks language feature is not enabled and that I should enable it with "-fblocks". When I add that compiler flag, the compile fails immediately saying "unknown argument: '-fblocks'" Is this perhaps an incomplete feature? Regards, Eric Mader

Your install dir has a whitespace. Have you tried quoting? e.g. <LLVMInstallDir>"C:\Program Files (x86)\LLVM"</LLVMInstallDir> Best regards, Rafael Auler On Mon, Sep 29, 2014 at 7:38 PM, Eric Mader <emader at gmx.us> wrote: > I changed tooset-vs2013.props to this: > > <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" >

I replaced all instances of "$(Platform)" with "x64" for the x64 .props file and it still fails, so it looks like that guess was wrong as well. Regards, Eric On 9/29/14, 2:11 PM, Eric Mader wrote: > Quoting doesn't seem to make a difference. Strangely, the Win32 > toolset seems to work. (Where "work" means that clang runs and > produces a bunch of

I was hoping to not have to build LLVM myself, especially on Windows. Can anybody help me with the Windows installer? Failing that, I find the directions for how to compile on Windows hard to follow? Can I build using Cygwin? Regards, Eric On 9/29/14, 8:11 AM, Rafael Auler wrote: > I'm not sure about the Windows installer, but if you build and install > LLVM for Windows from the

Open the file toolset-vs2013.props and you'll understand what's happening and where the path is set. It tries to fetch the LLVM installation path from the Windows registry. Just fix this (maybe editing your registry or editing the .props file, whatever suits you best). On Mon, Sep 29, 2014 at 5:33 PM, Eric Mader <emader at gmx.us> wrote: > I copied the x64 toolsets by hand and

I’m trying to install LLVM-3.6.0-r218288-win32.exe on Windows 7 Ultimate x64. The install doesn’t complain, but the toolset doesn’t show up in either Visual Studio 2013 or Visual Studio 2010. Also I selected the choices to add LLVM to the path for every user and put an LLVM icon on the desktop. Neither of this happened. Can anyone tell me how to get this to work? Regards, Eric Mader

I believe that we provide a definition of size_t inside the compiler itself when clang is in MSVC compatibility mode. On Tue, Sep 30, 2014 at 5:51 PM, Eric Mader <emader at gmx.us> wrote: > I did some more investigation of the size_t size error. I misunderstood > what was happening. It turns out that size_t is already defined before my > prefix header is included. I added the

Hi Hans, Answers inline below. Regards, Eric On 9/30/14, 8:05 AM, Hans Wennborg wrote: > On Mon, Sep 29, 2014 at 7:56 PM, Eric Mader <emader at gmx.us> wrote: >> Hi Hans, >> >> I think installer.bat found my visual Studio installation because it >> installed the Win32 toolsets but not the x64 ones. (It took me a while to >> work this out ;-) I installed

Hi Hans, I think installer.bat found my visual Studio installation because it installed the Win32 toolsets but not the x64 ones. (It took me a while to work this out ;-) I installed the x64 toolsets by hand and they seem to work. I think the installer ran as administrator. I explicitly ran it that way again (asking it to uninstall first) just to be sure. It didn't seem to make any

Hi Reid, I copied the x64 toolsets by hand; they got installed to C:\Program Files (x86)\LLVM\tools\msbuild\x64; they just didn't get moved correctly by install.bat. I just verified that the LLVM-vs2013 toolset.props is correct. If it is a bitness problem, perhaps I'm failing to define something correctly? Regards, Eric On 9/30/14, 11:29 AM, Reid Kleckner wrote: > This looks

I'm trying to port a bunch of code from MacOS X to Windows. The code is a mixture of C, C++11 and Objective-C. (Some of the C++ code has bits of Objective-C mixed in, just for spice ;-) Since it builds on the Mac with clang, I thought that building on Windows with clang would mean that I wouldn't have to make a bunch of changes just related to a different compiler. For example, if I

I'm getting compile errors because size_t is getting redefined. My "forced include file" starts with: #if BUILDING_FOR_WINDOWS #define NOMINMAX /* deal with the fact that windef.h also defines BOOL */ #define BOOL WINBOOL #include <windows.h> #include <intrin.h> #undef BOOL #endif Looking at the preprocessor expansion of a typical .cpp file, I see that crtdefs.h

Hi Reid, Thanks for the reply. Comments inline below. Regards, Eric On 9/29/14, 5:51 PM, Reid Kleckner wrote: > I think any port will involve some changes, but it's really hard to > say which porting approach will be the least painless beforehand. > Aside from _MSC_VER incompatibilities messing up portability headers, > I think any changes you make to support clang on Windows

Chris and Bill, I have tested the proposed patch from... http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-August/016490.html under i686-apple-darwin9 and it solves the problems building gfortran from llvm svn. The resulting compiler works fine so can we get that patch in before 2.4 is release? Jack ps We do have one oddity left in llvm-gfortran from current llvm svn. I find

On Thu, Oct 30, 2008 at 5:23 PM, Jack Howarth <howarth at bromo.msbb.uc.edu> wrote: > Chris and Bill, > I have tested the proposed patch from... > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-August/016490.html > > under i686-apple-darwin9 and it solves the problems building gfortran > from llvm svn. The resulting compiler works fine so can we get that > patch

Looking back through the commits to llvm-gcc-4.2/trunk/gcc/config/i386/darwin.h, I see a total backout of format related warnings in r56923 followed by the reapplication of r569065 with a fix (r56946)... -- llvm-gcc-4.2/trunk/gcc/config/i386/darwin.h 2008/10/01 17:38:40 56923 +++ llvm-gcc-4.2/trunk/gcc/config/i386/darwin.h 2008/10/02 06:16:08 56946 @@ -101,6 +101,8 @@ %{!mmacosx-version-min=*:

On Oct 30, 2008, at 5:23 PM, Jack Howarth wrote: > ps We do have one oddity left in llvm-gfortran from current llvm > svn. I find everytime I compile something with llvm-gfortran that > I get a series of warning messages... > > f951: warning: command line option "-Wformat" is valid for C/C++/ > ObjC/ObjC++ but not for Fortran > f951: warning: command line option

On Thu, Oct 30, 2008 at 05:38:30PM -0700, Bill Wendling wrote: > On Thu, Oct 30, 2008 at 5:23 PM, Jack Howarth <howarth at bromo.msbb.uc.edu> wrote: > > Chris and Bill, > > I have tested the proposed patch from... > > > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-August/016490.html > > > > under i686-apple-darwin9 and it solves the problems

On Oct 30, 2008, at 11:02 PM, Chris Lattner wrote: > On Oct 30, 2008, at 5:23 PM, Jack Howarth wrote: >> ps We do have one oddity left in llvm-gfortran from current llvm >> svn. I find everytime I compile something with llvm-gfortran that >> I get a series of warning messages... >> >> f951: warning: command line option "-Wformat" is valid for C/C++/