Russell Wallace
2010-Feb-14 05:41 UTC
[LLVMdev] -version displays DEBUG on Visual C++ release build
C:\llvm\bin>llc -version Low Level Virtual Machine (http://llvm.org/): llvm version 2.6svn DEBUG build. Built Jan 31 2010(20:46:01). Registered Targets: x86 - 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 I did specify the release build with cmake; the lack of crashing on exit of programs compiled therewith confirms that :-) As far as I can see, the reason for the incorrect reporting is in CommandLine.cpp: #ifndef __OPTIMIZE__ cout << "DEBUG build"; #else cout << "Optimized build"; #endif According to a Google search, gcc sets __OPTIMIZE__ when -O2 or better is used, so presumably that's the intent of the above and the reason it doesn't work with Visual C++. I'd ideally like my compiler to report the version of llvm it was linked with (as well as its own version), so output of incorrect information is a problem. Does anyone know of a solution to this?
Russell Wallace
2010-Feb-14 09:28 UTC
[LLVMdev] -version displays DEBUG on Visual C++ release build
Got it. You can define the relevant symbol at cmake stage, using a command like this: \cmake-2.8.0-win32-x86\bin\cmake.exe -DCMAKE_BUILD_TYPE=Release "-DCMAKE_CXX_FLAGS_RELEASE=/MD /O2 /Ob2 /D NDEBUG /D __OPTIMIZE__" c:\llvm-2.6 On Sun, Feb 14, 2010 at 5:41 AM, Russell Wallace <russell.wallace at gmail.com> wrote:> C:\llvm\bin>llc -version > Low Level Virtual Machine (http://llvm.org/): > llvm version 2.6svn > DEBUG build. > Built Jan 31 2010(20:46:01). > > Registered Targets: > x86 - 32-bit X86: Pentium-Pro and above > x86-64 - 64-bit X86: EM64T and AMD64 > > I did specify the release build with cmake; the lack of crashing on > exit of programs compiled therewith confirms that :-) As far as I can > see, the reason for the incorrect reporting is in CommandLine.cpp: > > #ifndef __OPTIMIZE__ > cout << "DEBUG build"; > #else > cout << "Optimized build"; > #endif > > According to a Google search, gcc sets __OPTIMIZE__ when -O2 or better > is used, so presumably that's the intent of the above and the reason > it doesn't work with Visual C++. > > I'd ideally like my compiler to report the version of llvm it was > linked with (as well as its own version), so output of incorrect > information is a problem. Does anyone know of a solution to this? >
Óscar Fuentes
2010-Feb-15 11:57 UTC
[LLVMdev] Labeling builds as Release/Debug (was: -version displays DEBUG on Visual C++ release build)
Russell Wallace <russell.wallace at gmail.com> writes:> C:\llvm\bin>llc -version > Low Level Virtual Machine (http://llvm.org/): > llvm version 2.6svn > DEBUG build. > Built Jan 31 2010(20:46:01). > > Registered Targets: > x86 - 32-bit X86: Pentium-Pro and above > x86-64 - 64-bit X86: EM64T and AMD64 > > I did specify the release build with cmake; the lack of crashing on > exit of programs compiled therewith confirms that :-) As far as I can > see, the reason for the incorrect reporting is in CommandLine.cpp: > > #ifndef __OPTIMIZE__ > cout << "DEBUG build"; > #else > cout << "Optimized build"; > #endif > > According to a Google search, gcc sets __OPTIMIZE__ when -O2 or better > is used, so presumably that's the intent of the above and the reason > it doesn't work with Visual C++.This doesn't seems right to me. A debug build is has debug symbols and asserts enabled, while a release build has not. The activation of optimizations doesn't imply a release build. A slightly better criteria is the presence of NDEBUG, which is enabled by default on release builds by configure and cmake, and has the advantage of being portable.
Russell Wallace
2010-Feb-15 12:17 UTC
[LLVMdev] Labeling builds as Release/Debug (was: -version displays DEBUG on Visual C++ release build)
On Mon, Feb 15, 2010 at 11:57 AM, Óscar Fuentes <ofv at wanadoo.es> wrote:> This doesn't seems right to me. A debug build is has debug symbols and > asserts enabled, while a release build has not. The activation of > optimizations doesn't imply a release build. A slightly better criteria > is the presence of NDEBUG, which is enabled by default on release builds > by configure and cmake, and has the advantage of being portable.Yeah, NDEBUG is the criterion I'm using for my own code. But the existing code does use __OPTIMIZE__, so right now that does need to be set to get the correct version display on the release build. It adds an additional note as to whether NDEBUG was set.