[LLVMdev] size_t?

Eric Mader emader at gmx.us
Wed Oct 1 10:12:56 PDT 2014


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>


More information about the llvm-dev mailing list