Compiling LLVM 2.7 with Visual Studio 2010.

Hey,

Downloaded the release, used CMake to create solution… building mostly seems to be OK, except for a couple of compiler errors.

warning C4090: ‘function’ : different ‘const’ qualifiers d:\companyone\external\llvm\source\llvm-2.7\lib\support\regengine.inc 188
error C2248: ‘llvm::EquivalenceClasses::ECValue::ECValue’ : cannot access private member declared in class ‘llvm::EquivalenceClasses::ECValue’ C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xmemory 208
error C2668: ‘llvm::next’ : ambiguous call to overloaded function D:\CompanyOne\External\LLVM\source\llvm-2.7\lib\Transforms\Scalar\LoopStrengthReduce.cpp 2820
error C2440: ‘initializing’ : cannot convert from ‘int’ to ‘const llvm::TargetRegisterClass *’ C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\utility 163
error C2439: ‘std::_Pair_base<_Ty1,_Ty2>::second’ : member could not be initialized C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\utility 163

it totals to 15 build errors and 2 warnings, but most of them are repeats of the above 5…
Are these known issues? Or did I fail to set some setting?

3 of the errors come from usage of templates, hence the file names end up somewhere in the VS SDK, I can provide more details if required though…

Tom.

Hey,

So I tried to fix these errors, and have everything compiling now… not too difficult, just annoying.

error C2248: 'llvm::EquivalenceClasses<

::ECValue::ECValue’ : cannot access private member declared in class ‘llvm::EquivalenceClasses::ECValue’ C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xmemory 208

I moved:

// ECValue ctor - Start out with EndOfList pointing to this node, Next is Null, isLeader = true.
ECValue(const ElemTy &Elt)
: Leader(this), Next((ECValue*)(intptr_t)1), Data(Elt) {}

into the public section of the ECValue class, seemed to solve that one…

Sorry for just talking to myself here, just trying to keep people in the loop on my findings.
The problem seems to be a much larger issue with the Visual Studio 2010 C++ Compiler and not really related to clang/llvm. The following snippet of code does NOT compile in 2010…

#include
int main(int argc, char* argv[])
{
std::pair<int, void*> mypair(0, NULL);
return 0;
}

Tom.

That's perfectly fine -- it never #includes <utility>,
so there's no reason for std::pair to be in scope.

#include
int main(int argc, char* argv[])
{
std::pair<int, void*> mypair(0, (void*)NULL);
return 0;
}

compiles fine though…
couple people have reported the same issue actually, and apparently this is by design due to C++0x:

https://connect.microsoft.com/VisualStudio/feedback/details/520043/error-converting-from-null-to-a-pointer-type-in-std-pair?wa=wsignin1.0#tabs

Tom.

K, last one…

Global search and replace in LLVM and Clang for NULL → nullptr, and a couple of locations where 0 is used instead of a nullptr, makes both compile.

Apart from the errors I mentioned earlier about the private/public method, and the setjmp related stuff.

Not sure if it compiles with any other compiler now, so I won’t be submitting this null->nullptr change, but the other errors might be worth taking…

Tom.

hi,

K, last one…

Global search and replace in LLVM and Clang for NULL → nullptr, and a couple of locations where 0 is used instead of a nullptr, makes both compile.

Maybe we should define something like

#ifdef VS2010
#undef NULL
#define NULL nullptr
#end

in llvm/Support/Compiler.h

best regards
–ether

Last there is a gazillion errors around the fact that Microsoft for some
crazy stupid reason has defined setjmp to _setjmp, and thus the
generated intrinsics.gen goes completely insane everywhere. I'm sure
this is a legacy thing in visual studios libraries, but wow...

In LowerInvoke.cpp change this:
#if defined(_MSC_VER) && defined(setjmp)
#define setjmp_undefined_for_visual_studio
#undef setjmp
#endif

to this:
#if defined(_MSC_VER) && defined(setjmp) && _MSC_VER < 600
#define setjmp_undefined_for_visual_studio
#undef setjmp
#endif

Apparently setjmp IS defined to _setjmp everywhere, so if we don't undef
it, everything "just works".

There was also an error about next() being ambigous in one file (don't
remember which one right now), changing that to llvm::next() worked.

As for the null pointer issue, I only encountered it in 2 places in
llvm, an explicit cast of 0, or a helper variable of the correct type
helped.

Anyway, my solution to this was to make a 'intrinsics.gen.proxy', which
undefs that macro and then includes the intrinsics.gen, and then all
includes to intrinsics.gen, I modified to include the proxy. This
guarantees that at least the Instrinsic namespace is always setup
correctly... and you're left with a couple other files where it still
seems to be defined, so I just undef'ed it for the whole file in those
files as well...

Is there any interest in these changes applied to trunk? and if so how
do I proceed... I'm fine keeping these changes local and integrate, but
I figure there is more users out there wanting to move to VS2010 at some
point.

Yes please apply to trunk if it doesn't break anything, and if the
changes aren't too big (I don' think you need to replace all 0 with
null, just the ones that cause problems).

Best regards,
--Edwin