(original) (raw)

$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\LLVM\LLVM)

$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\LLVM\LLVM)

$(LLVMInstallDir)\msbuild-bin;$(ExecutablePath)

$(LLVMInstallDir)\lib\clang\3.6\lib\windows;$(LibraryPath)

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@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@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
:187:

1> In file included from :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:

-m32
-fmsc-version=1700
%(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@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,
\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@cs.uiuc.edu
http://llvm.cs.uiuc.edu

http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________

LLVM Developers mailing list

LLVMdev@cs.uiuc.edu
http://llvm.cs.uiuc.edu

http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev