Hi all,
I have been experimenting with getting LLVM to build with MSVC8 express.
I have succeeded in getting trunk to build and run the Fibonacci example in
release mode. I have found various minor problems with the build system.
First, it appears not to be able to run the configure subproject commands
if there is a space in the directory path.
Secondly, it fails to build different subprojects with release and debug
builds. In debug mode, it does not create the Analysis.lib, but this does
not fail in release. This in turn precludes a successful general build in
the debug mode.
Thirdly, in release mode, MSVC complains about the use of Debug in
llvmAsmParser.y
1>c:\llvm\lib\AsmParser\llvmAsmParser.y(3124) : error C2065: 'Debug'
:
undeclared identifier
e.g. below.
// common code from the two 'RunVMAsmParser' functions
static Module* RunParser(Module * M) {
llvmAsmlineno = 1; // Reset the current line number...
CurModule.CurrentModule = M;
#if YYDEBUG
yydebug = Debug;
#endif
// Check to make sure the parser succeeded
if (yyparse()) {
if (ParserResult)
delete ParserResult;
return 0;
}
Cheers,
George Russell
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20071111/f4a660e0/attachment.html>
George,> I have been experimenting with getting LLVM to build with > MSVC8 express. > > I have succeeded in getting trunk to build and run the > Fibonacci example in release mode. I have found various minor > problems with the build system. First, it appears not to be > able to run the configure subproject commands if there is a > space in the directory path.Should be ok now. Thanks for the heads up.> Secondly, it fails to build different subprojects with > release and debug builds. In debug mode, it does not create > the Analysis.lib, but this does not fail in release. This in > turn precludes a successful general build in the debug mode.Strange, this works for me (tm). What doesn't build there? A single file? The whole module?> Thirdly, in release mode, MSVC complains about the use of > Debug in llvmAsmParser.y > 1>c:\llvm\lib\AsmParser\llvmAsmParser.y(3124) : error C2065: > 'Debug' : > 1>undeclared identifier > e.g. below. > // common code from the two 'RunVMAsmParser' functions static > Module* RunParser(Module * M) { > > llvmAsmlineno = 1; // Reset the current line number... > CurModule.CurrentModule = M; > #if YYDEBUG > yydebug = Debug; > #endif > > // Check to make sure the parser succeeded > if (yyparse()) { > if (ParserResult) > delete ParserResult; > return 0; > }Please try to fully rebuild the AsmParser project. This will regenerate the llvmAsmParser.cpp from llvmAsmParser.y, which should resolve this issue. Regards Hartmut
Hi, I had to add an include statement for the math header to LiveIntervalAnalysis.h to get it to compile today e.g #ifndef LLVM_CODEGEN_LIVEINTERVAL_ANALYSIS_H #define LLVM_CODEGEN_LIVEINTERVAL_ANALYSIS_H #include <math.h> It seems then to work without failures; odd. However, the deprecation warnings are not suppressed for std::_Uninit_Copy and std::_Copy_Opt (warning 4996) in xutility and memory headers respectively e.g.>C:\Program Files\Microsoft Visual Studio 8\VC\include\memory(93) : warningC4996: 'std::_Uninit_copy' was declared deprecated 5> C:\Program Files\Microsoft Visual Studio 8\VC\include\memory(82) : see declaration of 'std::_Uninit_copy' 5> Message: 'You have used a std:: construct that is not safe. See documentation on how to use the Safe Standard C++ Library' 5> c:\llvm\include\llvm/ADT/SmallVector.h(427) : see reference to function template instantiation '_FwdIt std::uninitialized_copy<T*,T*>(_InIt,_InIt,_FwdIt)' being compiled 5> with 5> [ 5> _FwdIt=llvm::TargetAlignElem *, 5> T=llvm::TargetAlignElem, 5> _InIt=llvm::TargetAlignElem * 5> ] The project would appear to have the right pre-processor definitions to suppress such warnings, but they still occur. The compiler issues _many_ warnings about conversions between uint64_t and uint, which seems to be a very common occurance. Is there any point in LLVM to having such conversions present implicitly vs explicitly (suppressing the warnings?) other than syntactic clarity? Cheers, George Russell -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071112/c7ba7ed7/attachment.html>