MSVC 8 Build

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

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) : warning C4996: ‘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

George,

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.

What didn't work before you added this?

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) :
>warning C4996: '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.

Compilation of what files produces these warnings?

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?

I didn't suppress these warnings because I'm working on fixing them instead.
This is a tedious process, though, and it probably will take me some time to
finish.

Regards Hartmut