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 http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?revision=218666&view=markup#l3157 I don't see any obvious bugs here. On Tue, Sep 30, 2014 at 6:50 PM, Eric Mader <emader at gmx.us> wrote:> But crtdefs.h says: > > #ifdef _WIN64 > typedef unsigned __int64 size_t; > #else > typedef _W64 unsigned int size_t; > #endif > > Which conflicts with the built-in definition, that seems to be equivalent > to: > > typedef unsigned int size_t; > > What determines the built-in type of size_t? Is there some setting or > variable I can define to change it? > > Regards, > Eric > > > > > On 9/30/14, 3:21 PM, David Majnemer wrote: > > 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 following static_asserts to the font >> of the header: >> >> static_assert(sizeof(size_t) != 4, "sizeof(size_t) == 4"); >> static_assert(sizeof(size_t) != 8, "sizeof(size_t) == 8"); >> >> The first static_assert fires: >> >> 1>Build started 9/30/2014 2:29:54 PM. >> 1>clang-cl.exe : warning : argument unused during compilation: '/Gm-' >> 1>clang-cl.exe : warning : argument unused during compilation: '/GS' >> 1>clang-cl.exe : warning : argument unused during compilation: >> '/fp:precise' >> 1>clang-cl.exe : warning : argument unused during compilation: >> '/FdDebug\x64\vc120.pdb' >> 1>clang-cl.exe : warning : argument unused during compilation: '/Gd' >> 1> In file included from <built-in>:187: >> 1> In file included from <command line>:19: >> 1>[elided header file name](9,1): error : static_assert failed >> "sizeof(size_t) == 4" >> 1> static_assert(sizeof(size_t) != 4, "sizeof(size_t) == 4"); >> 1> ^ ~~~~~~~~~~~~~~~~~~~ >> >> Later on, I get an error saying that crtdefs.h is trying to redefine >> size_t from an unsigned int to an unsigned long long... >> >> Perhaps one of my preprocessor defines is causing these errors: >> >> WIN32 >> _DEBUG >> _WINDOWS >> _USRDLL >> _SCL_SECURE_NO_WARNINGS >> _CRT_SECURE_NO_WARNINGS >> _WIN64 >> _x86_64_ = 1 >> >> (I added the "SECURE_NO_WARNINGS" defines when I ported an earlier >> version of this code to VS 2005; don't remember why any more...) >> (There are a couple of other defines that are specific to the DLL I'm >> trying to build) >> >> Regards, >> Eric Mader >> >> >> On 9/30/14, 1:01 PM, Eric Mader wrote: >> >> 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 like some kind of bitness conflict. If you are building for >> win64, are you sure clang is getting the -m64 argument? >> >> I recall that you copied the win32 platform toolset xml files over by >> hand, and I don't think they will have the correct flags. If you see this >> line in the x64 toolset.props file, replace -m32 with -m64 and try again: >> <AdditionalOptions>-m32 -fmsc-version=1700 >> %(AdditionalOptions)</AdditionalOptions> >> >> In the meantime, I think Hans is trying to fix the installation of >> those xml files and hopefully that will fix issues for other users going >> forwards. >> >> On Tue, Sep 30, 2014 at 1:55 PM, Eric Mader <emader at gmx.us> wrote: >> >>> 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 defines size_t like this: >>> >>> typedef unisgned __int64 size_t; >>> >>> Later on, <LLVM>\lib\clang\3.6.0\includes\stddef.h defines it as: >>> >>> typedef unsigned int size_t; >>> >>> Is there some other magic I need to do to get these to work? >>> >>> I'm also seeing a bunch of errors like this having to do with intrinsics: >>> >>> 1> In file included from C:\Program Files (x86)\Microsoft Visual Studio >>> 12.0\VC\include\algorithm:6: >>> 1> In file included from C:\Program Files (x86)\Microsoft Visual Studio >>> 12.0\VC\include\xmemory:6: >>> 1> In file included from C:\Program Files (x86)\Microsoft Visual Studio >>> 12.0\VC\include\xmemory0:909: >>> 1> In file included from C:\Program Files >>> (x86)\LLVM\msbuild-bin\..\lib\clang\3.6.0\include\intrin.h:34: >>> 1> In file included from C:\Program Files >>> (x86)\LLVM\msbuild-bin\..\lib\clang\3.6.0\include\x86intrin.h:29: >>> 1> In file included from C:\Program Files >>> (x86)\LLVM\msbuild-bin\..\lib\clang\3.6.0\include\immintrin.h:28: >>> 1>C:\Program Files >>> (x86)\LLVM\msbuild-bin\..\lib\clang\3.6.0\include\mmintrin.h(52,40): error >>> : cannot initialize a parameter of type '__attribute__((__vector_size__(2 * >>> sizeof(int)))) int' (vector of 2 'int' values) with an rvalue of type >>> '__v2si' (aka 'int') >>> 1> return __builtin_ia32_vec_ext_v2si((__v2si)__m, 0); >>> 1> ^~~~~~~~~~~ >>> >>> I suspect that these might be caused by the same thing as the size_t >>> problem... >>> >>> Regards, >>> Eric Mader >>> >>> >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> >> >> >> >> _______________________________________________ >> LLVM Developers mailing listLLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140930/7a933799/attachment.html>
I enabled verbose build logs in VS and found that the "-m64 -fmsc-version=1800" options didn't appear: 1> C:\Program Files (x86)\LLVM\msbuild-bin\CL.exe /c /IC:[elided] /IC:[elided] /IC:[elided] /IC:[elided] /IC:[elided] /IC:[elided] /Zi /nologo /W3 /WX- /Od /D WIN32 /D _DEBUG /D _WINDOWS /D _USRDLL /D [elided] /D _t_env_os_WIN32 /D [elided] /D _SCL_SECURE_NO_WARNINGS /D _CRT_SECURE_NO_WARNINGS /D [elided] /D _WIN64 /D "__x86_64__= 1" /D _WINDLL /D _UNICODE /D UNICODE /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fo"Debug\x64\\" /Fd"Debug\x64\vc120.pdb" /Gd /TP /wd4068 /wd4200 /wd4244 /wd4267 /wd4305 /wd4309 /wd4311 /wd4800 /FIC:[elided].h /errorReport:prompt -ferror-limit=1000 -Xclang -fblocks [elided].cpp I added them as Additional Options for the file I'm trying to compile, and the size_t errors went away. So it looks like the problem is that these options aren't getting applied by the toolset, even though they are in the toolset.props file: <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <Import Project="$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\v120\Microsoft.Cpp.$(Platform).v120.props" Condition="Exists('$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\v120\Microsoft.Cpp.$(Platform).v120.props')"/> <Import Project="$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\v120\Toolset.props" Condition="Exists('$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\v120\Toolset.props')"/> <PropertyGroup> <LLVMInstallDir>$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\LLVM\LLVM)</LLVMInstallDir> <LLVMInstallDir Condition="'$(LLVMInstallDir)' == ''">$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\LLVM\LLVM)</LLVMInstallDir> <ExecutablePath>$(LLVMInstallDir)\msbuild-bin;$(ExecutablePath)</ExecutablePath> <LibraryPath>$(LLVMInstallDir)\lib\clang\3.6\lib\windows;$(LibraryPath)</LibraryPath> </PropertyGroup> <ItemDefinitionGroup> <ClCompile> <!-- Set the value of _MSC_VER to claim for compatibility --> <AdditionalOptions>-m64 -fmsc-version=1800 %(AdditionalOptions)</AdditionalOptions> </ClCompile> </ItemDefinitionGroup> </Project> This file is located at C:\Program Files (x86)\MSBuild\Microsoft.Cpp\4.0\V120\Platforms\x64\PlatformToolsets\LLVM-vs2013 Regards, Eric On 9/30/14, 7:31 PM, David Majnemer wrote:> 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 > http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?revision=218666&view=markup#l3157 > > I don't see any obvious bugs here. > > > On Tue, Sep 30, 2014 at 6:50 PM, Eric Mader <emader at gmx.us > <mailto:emader at gmx.us>> wrote: > > But crtdefs.h says: > > #ifdef _WIN64 > typedef unsigned __int64 size_t; > #else > typedef _W64 unsigned int size_t; > #endif > > Which conflicts with the built-in definition, that seems to be > equivalent to: > > typedef unsigned int size_t; > > What determines the built-in type of size_t? Is there some setting > or variable I can define to change it? > > Regards, > Eric > > > > > On 9/30/14, 3:21 PM, David Majnemer wrote: >> 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 >> <mailto: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 following static_asserts to the font of the header: >> >> static_assert(sizeof(size_t) != 4, "sizeof(size_t) == 4"); >> static_assert(sizeof(size_t) != 8, "sizeof(size_t) == 8"); >> >> The first static_assert fires: >> >> 1>Build started 9/30/2014 2:29:54 PM. >> 1>clang-cl.exe : warning : argument unused during >> compilation: '/Gm-' >> 1>clang-cl.exe : warning : argument unused during >> compilation: '/GS' >> 1>clang-cl.exe : warning : argument unused during >> compilation: '/fp:precise' >> 1>clang-cl.exe : warning : argument unused during >> compilation: '/FdDebug\x64\vc120.pdb' >> 1>clang-cl.exe : warning : argument unused during >> compilation: '/Gd' >> 1> In file included from <built-in>:187: >> 1> In file included from <command line>:19: >> 1>[elided header file name](9,1): error : static_assert >> failed "sizeof(size_t) == 4" >> 1> static_assert(sizeof(size_t) != 4, "sizeof(size_t) == 4"); >> 1> ^ ~~~~~~~~~~~~~~~~~~~ >> >> Later on, I get an error saying that crtdefs.h is trying to >> redefine size_t from an unsigned int to an unsigned long long... >> >> Perhaps one of my preprocessor defines is causing these errors: >> >> WIN32 >> _DEBUG >> _WINDOWS >> _USRDLL >> _SCL_SECURE_NO_WARNINGS >> _CRT_SECURE_NO_WARNINGS >> _WIN64 >> _x86_64_ = 1 >> >> (I added the "SECURE_NO_WARNINGS" defines when I ported an >> earlier version of this code to VS 2005; don't remember why >> any more...) >> (There are a couple of other defines that are specific to the >> DLL I'm trying to build) >> >> Regards, >> Eric Mader >> >> >> On 9/30/14, 1:01 PM, Eric Mader wrote: >>> 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 like some kind of bitness conflict. If you are >>>> building for win64, are you sure clang is getting the -m64 >>>> argument? >>>> >>>> I recall that you copied the win32 platform toolset xml >>>> files over by hand, and I don't think they will have the >>>> correct flags. If you see this line in the x64 >>>> toolset.props file, replace -m32 with -m64 and try again: >>>> <AdditionalOptions>-m32 -fmsc-version=1700 >>>> %(AdditionalOptions)</AdditionalOptions> >>>> >>>> In the meantime, I think Hans is trying to fix the >>>> installation of those xml files and hopefully that will fix >>>> issues for other users going forwards. >>>> >>>> On Tue, Sep 30, 2014 at 1:55 PM, Eric Mader <emader at gmx.us >>>> <mailto:emader at gmx.us>> wrote: >>>> >>>> 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 defines size_t like this: >>>> >>>> typedef unisgned __int64 size_t; >>>> >>>> Later on, <LLVM>\lib\clang\3.6.0\includes\stddef.h >>>> defines it as: >>>> >>>> typedef unsigned int size_t; >>>> >>>> Is there some other magic I need to do to get these to >>>> work? >>>> >>>> I'm also seeing a bunch of errors like this having to >>>> do with intrinsics: >>>> >>>> 1> In file included from C:\Program Files >>>> (x86)\Microsoft Visual Studio 12.0\VC\include\algorithm:6: >>>> 1> In file included from C:\Program Files >>>> (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory:6: >>>> 1> In file included from C:\Program Files >>>> (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory0:909: >>>> 1> In file included from C:\Program Files >>>> (x86)\LLVM\msbuild-bin\..\lib\clang\3.6.0\include\intrin.h:34: >>>> 1> In file included from C:\Program Files >>>> (x86)\LLVM\msbuild-bin\..\lib\clang\3.6.0\include\x86intrin.h:29: >>>> 1> In file included from C:\Program Files >>>> (x86)\LLVM\msbuild-bin\..\lib\clang\3.6.0\include\immintrin.h:28: >>>> 1>C:\Program Files >>>> (x86)\LLVM\msbuild-bin\..\lib\clang\3.6.0\include\mmintrin.h(52,40): >>>> error : cannot initialize a parameter of type >>>> '__attribute__((__vector_size__(2 * sizeof(int)))) int' >>>> (vector of 2 'int' values) with an rvalue of type >>>> '__v2si' (aka 'int') >>>> 1> return __builtin_ia32_vec_ext_v2si((__v2si)__m, 0); >>>> 1> ^~~~~~~~~~~ >>>> >>>> I suspect that these might be caused by the same thing >>>> as the size_t problem... >>>> >>>> Regards, >>>> Eric Mader >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> >>>> http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> >> http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141001/e68c7790/attachment.html>
Just did some more checking and found that for Win32 to Additional Options *do* appear. Any ideas what's going on here? Regards, Eric On 10/1/14, 6:58 AM, Eric Mader wrote:> I enabled verbose build logs in VS and found that the "-m64 > -fmsc-version=1800" options didn't appear: > > 1> C:\Program Files (x86)\LLVM\msbuild-bin\CL.exe /c /IC:[elided] > /IC:[elided] /IC:[elided] /IC:[elided] /IC:[elided] /IC:[elided] /Zi > /nologo /W3 /WX- /Od /D WIN32 /D _DEBUG /D _WINDOWS /D _USRDLL /D > [elided] /D _t_env_os_WIN32 /D [elided] /D _SCL_SECURE_NO_WARNINGS /D > _CRT_SECURE_NO_WARNINGS /D [elided] /D _WIN64 /D "__x86_64__= 1" /D > _WINDLL /D _UNICODE /D UNICODE /Gm- /EHsc /RTC1 /MDd /GS /fp:precise > /Zc:wchar_t /Zc:forScope /Fo"Debug\x64\\" /Fd"Debug\x64\vc120.pdb" /Gd > /TP /wd4068 /wd4200 /wd4244 /wd4267 /wd4305 /wd4309 /wd4311 /wd4800 > /FIC:[elided].h /errorReport:prompt -ferror-limit=1000 -Xclang > -fblocks [elided].cpp > > I added them as Additional Options for the file I'm trying to compile, > and the size_t errors went away. > > So it looks like the problem is that these options aren't getting > applied by the toolset, even though they are in the toolset.props file: > > <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> > <Import > Project="$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\v120\Microsoft.Cpp.$(Platform).v120.props"Condition="Exists('$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\v120\Microsoft.Cpp.$(Platform).v120.props')"/> > <Import > Project="$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\v120\Toolset.props"Condition="Exists('$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\v120\Toolset.props')"/> > > <PropertyGroup> > <LLVMInstallDir>$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\LLVM\LLVM)</LLVMInstallDir> > <LLVMInstallDir Condition="'$(LLVMInstallDir)' == > ''">$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\LLVM\LLVM)</LLVMInstallDir> > <ExecutablePath>$(LLVMInstallDir)\msbuild-bin;$(ExecutablePath)</ExecutablePath> > <LibraryPath>$(LLVMInstallDir)\lib\clang\3.6\lib\windows;$(LibraryPath)</LibraryPath> > </PropertyGroup> > > <ItemDefinitionGroup> > <ClCompile> > <!-- Set the value of _MSC_VER to claim for compatibility --> > <AdditionalOptions>-m64 -fmsc-version=1800 > %(AdditionalOptions)</AdditionalOptions> > </ClCompile> > </ItemDefinitionGroup> > </Project> > > This file is located at C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\4.0\V120\Platforms\x64\PlatformToolsets\LLVM-vs2013 > > Regards, > Eric > > On 9/30/14, 7:31 PM, David Majnemer wrote: >> 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 >> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?revision=218666&view=markup#l3157 >> >> I don't see any obvious bugs here. >> >> >> On Tue, Sep 30, 2014 at 6:50 PM, Eric Mader <emader at gmx.us >> <mailto:emader at gmx.us>> wrote: >> >> But crtdefs.h says: >> >> #ifdef _WIN64 >> typedef unsigned __int64 size_t; >> #else >> typedef _W64 unsigned int size_t; >> #endif >> >> Which conflicts with the built-in definition, that seems to be >> equivalent to: >> >> typedef unsigned int size_t; >> >> What determines the built-in type of size_t? Is there some >> setting or variable I can define to change it? >> >> Regards, >> Eric >> >> >> >> >> On 9/30/14, 3:21 PM, David Majnemer wrote: >>> 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 >>> <mailto: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 following static_asserts to the font of the header: >>> >>> static_assert(sizeof(size_t) != 4, "sizeof(size_t) == 4"); >>> static_assert(sizeof(size_t) != 8, "sizeof(size_t) == 8"); >>> >>> The first static_assert fires: >>> >>> 1>Build started 9/30/2014 2:29:54 PM. >>> 1>clang-cl.exe : warning : argument unused during >>> compilation: '/Gm-' >>> 1>clang-cl.exe : warning : argument unused during >>> compilation: '/GS' >>> 1>clang-cl.exe : warning : argument unused during >>> compilation: '/fp:precise' >>> 1>clang-cl.exe : warning : argument unused during >>> compilation: '/FdDebug\x64\vc120.pdb' >>> 1>clang-cl.exe : warning : argument unused during >>> compilation: '/Gd' >>> 1> In file included from <built-in>:187: >>> 1> In file included from <command line>:19: >>> 1>[elided header file name](9,1): error : static_assert >>> failed "sizeof(size_t) == 4" >>> 1> static_assert(sizeof(size_t) != 4, "sizeof(size_t) == 4"); >>> 1> ^ ~~~~~~~~~~~~~~~~~~~ >>> >>> Later on, I get an error saying that crtdefs.h is trying to >>> redefine size_t from an unsigned int to an unsigned long long... >>> >>> Perhaps one of my preprocessor defines is causing these errors: >>> >>> WIN32 >>> _DEBUG >>> _WINDOWS >>> _USRDLL >>> _SCL_SECURE_NO_WARNINGS >>> _CRT_SECURE_NO_WARNINGS >>> _WIN64 >>> _x86_64_ = 1 >>> >>> (I added the "SECURE_NO_WARNINGS" defines when I ported an >>> earlier version of this code to VS 2005; don't remember why >>> any more...) >>> (There are a couple of other defines that are specific to >>> the DLL I'm trying to build) >>> >>> Regards, >>> Eric Mader >>> >>> >>> On 9/30/14, 1:01 PM, Eric Mader wrote: >>>> 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 like some kind of bitness conflict. If you are >>>>> building for win64, are you sure clang is getting the -m64 >>>>> argument? >>>>> >>>>> I recall that you copied the win32 platform toolset xml >>>>> files over by hand, and I don't think they will have the >>>>> correct flags. If you see this line in the x64 >>>>> toolset.props file, replace -m32 with -m64 and try again: >>>>> <AdditionalOptions>-m32 -fmsc-version=1700 >>>>> %(AdditionalOptions)</AdditionalOptions> >>>>> >>>>> In the meantime, I think Hans is trying to fix the >>>>> installation of those xml files and hopefully that will >>>>> fix issues for other users going forwards. >>>>> >>>>> On Tue, Sep 30, 2014 at 1:55 PM, Eric Mader <emader at gmx.us >>>>> <mailto:emader at gmx.us>> wrote: >>>>> >>>>> 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 defines size_t like this: >>>>> >>>>> typedef unisgned __int64 size_t; >>>>> >>>>> Later on, <LLVM>\lib\clang\3.6.0\includes\stddef.h >>>>> defines it as: >>>>> >>>>> typedef unsigned int size_t; >>>>> >>>>> Is there some other magic I need to do to get these to >>>>> work? >>>>> >>>>> I'm also seeing a bunch of errors like this having to >>>>> do with intrinsics: >>>>> >>>>> 1> In file included from C:\Program Files >>>>> (x86)\Microsoft Visual Studio 12.0\VC\include\algorithm:6: >>>>> 1> In file included from C:\Program Files >>>>> (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory:6: >>>>> 1> In file included from C:\Program Files >>>>> (x86)\Microsoft Visual Studio >>>>> 12.0\VC\include\xmemory0:909: >>>>> 1> In file included from C:\Program Files >>>>> (x86)\LLVM\msbuild-bin\..\lib\clang\3.6.0\include\intrin.h:34: >>>>> 1> In file included from C:\Program Files >>>>> (x86)\LLVM\msbuild-bin\..\lib\clang\3.6.0\include\x86intrin.h:29: >>>>> 1> In file included from C:\Program Files >>>>> (x86)\LLVM\msbuild-bin\..\lib\clang\3.6.0\include\immintrin.h:28: >>>>> 1>C:\Program Files >>>>> (x86)\LLVM\msbuild-bin\..\lib\clang\3.6.0\include\mmintrin.h(52,40): >>>>> error : cannot initialize a parameter of type >>>>> '__attribute__((__vector_size__(2 * sizeof(int)))) >>>>> int' (vector of 2 'int' values) with an rvalue of type >>>>> '__v2si' (aka 'int') >>>>> 1> return >>>>> __builtin_ia32_vec_ext_v2si((__v2si)__m, 0); >>>>> 1> ^~~~~~~~~~~ >>>>> >>>>> I suspect that these might be caused by the same thing >>>>> as the size_t problem... >>>>> >>>>> Regards, >>>>> Eric Mader >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> LLVM Developers mailing list >>>>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> >>>>> http://llvm.cs.uiuc.edu >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>> >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> >>> http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141001/2dacfa02/attachment.html>