[LLVMdev] size_t?

Eric Mader emader at gmx.us
Tue Sep 30 18:50:23 PDT 2014


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>


More information about the llvm-dev mailing list