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<ElemTy>::ECValue::ECValue' : cannot access private member declared in class 'llvm::EquivalenceClasses<ElemTy>::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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100501/cad08ca5/attachment.html>
Hey, So I tried to fix these errors, and have everything compiling now... not too difficult, just annoying. error C2248: 'llvm::EquivalenceClasses<> > ElemTy>::ECValue::ECValue' : cannot access private member declared in class > 'llvm::EquivalenceClasses<ElemTy>::ECValue' C:\Program Files > (x86)\Microsoft Visual Studio 10.0\VC\include\xmemory 208I 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.. ------ the cast errors from below... pretty weird, but the Microsofts compiler seems to not like passing in 0 as a pointer into the pair<> template if that argument is in reality a pointer. seems weird since if (bla == 0) works fine, but pair<int, void*>(0,0); does not, anyway, the fix was to just cast that 0... so pair<int, void*>(0, (void*)0); ------ 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... 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. Tom. On Sat, May 1, 2010 at 7:59 PM, Tom van Dijck <llvm at tomvandijck.com> wrote:> 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<ElemTy>::ECValue::ECValue' : cannot > access private member declared in class > 'llvm::EquivalenceClasses<ElemTy>::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. > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100501/1c14b5b8/attachment.html>
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 <vector>
int main(int argc, char* argv[])
{
std::pair<int, void*> mypair(0, NULL);
return 0;
}
Tom.
On Sat, May 1, 2010 at 8:57 PM, Tom van Dijck <llvm at tomvandijck.com>
wrote:
> Hey,
>
> So I tried to fix these errors, and have everything compiling now... not
> too difficult, just annoying.
>
> error C2248: 'llvm::EquivalenceClasses<
>>
>> ElemTy>::ECValue::ECValue' : cannot access private member
declared in
>> class 'llvm::EquivalenceClasses<ElemTy>::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..
>
> ------
>
> the cast errors from below... pretty weird, but the Microsofts compiler
> seems to not like passing in 0 as a pointer into the pair<> template
if that
> argument is in reality a pointer. seems weird since if (bla == 0) works
> fine, but pair<int, void*>(0,0); does not, anyway, the fix was to
just cast
> that 0... so pair<int, void*>(0, (void*)0);
>
> ------
>
> 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...
>
> 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.
>
> Tom.
>
>
> On Sat, May 1, 2010 at 7:59 PM, Tom van Dijck <llvm at
tomvandijck.com>wrote:
>
>> 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<ElemTy>::ECValue::ECValue' : cannot
>> access private member declared in class
>> 'llvm::EquivalenceClasses<ElemTy>::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.
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100501/df26a9fe/attachment.html>
On 05/02/2010 06:57 AM, Tom van Dijck wrote:> 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