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/c38e9fad/attachment.html>
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/20140930/45658ab3/attachment.html>
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>