I use Intel C++ Compiler v. 13 for OS Windows in MS Visual Studio 2010. This compiler support vectorize a code. I want to disable this option, but save enabled -O2 optimization. I set for this goal /Qvec- flag in Project -> Properties -> Configuration Properties -> C/C++ -> Command Line -> Additional Options window (label "Inherit from parent or project defaults" is enabled). In All options section shown these keys:
/Zi /nologo /W3 /Od /Ot /Qipo /Qopt-matmul /D "WIN32" /D "NDEBUG" /D
"_CONSOLE" /D "NOALIAS" /D "_UNICODE" /D "UNICODE" /EHsc /MT /GS /Gy
/fp:fast /QaxAVX /Zc:wchar_t /Zc:forScope /Qopenmp /Qstd=c99
/Qstd=c++11 /Fp"Release\mformat.pch" /Fa"Release\" /Fo"Release\"
/Fd"Release\vc100.pdb" /Qvec-report2 /Gd
But in compilation report output this messages:
service.cpp(164): warning : SIMD LOOP WAS VECTORIZED.
service.cpp(535): warning : SIMD LOOP WAS VECTORIZED.
service.cpp(543): warning : loop was not vectorized: nonstandard loop
is not a vectorization candidate.
etc...
And program time is not change. How i can disable vectorization and no set \Od key?
Found this in the document "A Guide to Vectorization with Intel® C++ Compilers"
To allow comparisons of vectorized with unvectorized code,
vectorization may be disabled with the switch /Qvec- (Windows*) or
-no-vec (Linux* or Mac OS* X).
Lots of additional good information on the Intel® Composer XE Suite page.
Related
I work on the CMake-based Qt project in MS Visual Studio. When I try to evaluate any method of a Qt object, I receive the error:
Function <blablabla> has no address, possibly due to compiler optimizations.
Image: QuickWatch evaluation error
I build in the DEBUG mode; I see the compiler invoked with no optimizations:
cl.exe ... /DWIN32 /D_WINDOWS /W3 /GR /EHsc /MDd /Zi /Ob0 /Od /RTC1
Also, I checked the PDBs are loaded:
Image: VS Modules Window with PDBs loaded
But nothing of this helps: all the objects evaluated well, but Qt's - are not.
Is there anything that will make the Visual Studio evaluate Qt objects' properties?
There are many posts about how to set the Runtime library in Visual Studio from CMake, but in my case it seems that Visual Studio is ignoring my setting.
I would like to build google-mock with /MD. This is the default setting in the project.
In a fresh build directory, built with:
cmake -G "Visual Studio 12 2013" -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=C:\Users\mrussell\workspace\opal2\o2win32\Libs\gtest\"1.7.0" -DCMAKE_CXX_FLAGS_RELEASE="/MD /O2 /Ob2 /D NDEBUG" ../googlemock
All my cmake variables seem correct
However, when I go to build, either via the command line (I'm used to linux..) or from Visual Studio, it uses the /MT flag.
My build command (targeting 32 bit):
call "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\vcvars32.bat"
msbuild /m:4 /property:Configuration=%build_type% ALL_BUILD.vcxproj
Output:
ClCompile:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\CL.exe /c /IC:\Users\mrussell\workspace\opal2\o2win32\Libs\gtest\g
test\include /IC:\Users\mrussell\workspace\opal2\o2win32\Libs\gtest\gtest /Zi /nologo /W4 /WX /O2 /Ob2 /Oy- /D WIN32 /D _WIND
OWS /D NDEBUG /D WIN32 /D _WINDOWS /D _UNICODE /D UNICODE /D WIN32 /D _WIN32 /D STRICT /D WIN32_LEAN_AND_MEAN /D GTEST_HAS_PT
HREAD=0 /D _HAS_EXCEPTIONS=1 /D "CMAKE_INTDIR=\"Release\"" /D _UNICODE /D UNICODE /Gm- /EHsc /MT /GS /fp:precise /Zc:wchar_t
/Zc:forScope /GR /Fo"gtest.dir\Release\\" /Fd"gtest.dir\Release\vc120.pdb" /Gd /TP /wd4127 /wd4251 /wd4275 /analyze- /errorRe
port:queue -J "C:\Users\mrussell\workspace\opal2\o2win32\Libs\gtest\gtest\src\gtest-all.cc"
(note the /MT hiding in there.)
In Visual Studio, I open the solution, choose release type Release, and in any of the targets, say gtest, Properties -> Configuration Properties -> C/C++ -> Code Generation, the Runtime Library is set to /MT, not /MD as set in the Cmake file.
Same thing happens if I try to build google-test (1.7.0)
Do I just not understand how to set these? Or is there a way to force Visual Studio to use the right flag without manually opening Visual Studio and setting it?
The CMake build systems of both google-test and google-mock aren't well behaved. They do not obey the compile options and runtime option set up by the user for good reason and override those with options that they consider reasonable for testing purposes.
To prevent the replacement of MD with MT you can set the option gtest_force_shared_crt to ON in the CMake cache. The modification of other compile options (e.g., warnings) however is done unconditionally.
I use the latest Intel compiler atop MVS 2013. I am developing a small application which currently consists of a static library with main functionality (9 classes) and an one-file console executable to test the former. I decided to build the application under release configuration to find out how faster it will become.
The problem is while the static library builds rather swiftly producing 13 MB .lib file (that is,as I found out, normal), the executable is taking very long time. I left it overnight and it is still hasn't been finished (currently over 12 hours). There has been no visible progress except mcpcom has been slowly increasing its memory usage to currently 1GB.
The static library compiling settings :
/MP /GS /GA /W3 /Gy /Zc:wchar_t /Zi /O2 /Fd"Release\vc120.pdb" /Qvec-report1 /D "WIN32" /D "NDEBUG" /D "_LIB" /D "_UNICODE" /D "UNICODE" /Qstd=c++11 /Qipo /Zc:forScope /Gd /Oi /MD /Fa"Release\" /EHsc /nologo /Fo"Release\" /Fp"Release\MyApplication_library.pch"
The executable compiling options:
/MP /GS /GA /W3 /Gy /Zc:wchar_t /I"C:\Work\MyApplication\MyApplication_library" /Zi /O2 /Fd"Release\vc120.pdb" /Qvec-report1 /D "_UNICODE" /D "UNICODE" /Qstd=c++11 /Qipo /Zc:forScope /Gd /Oi /MT /Fa"Release\" /EHsc /nologo /Fo"Release\" /Fp"Release\MyApplication_test.pch"
linker options
/OUT:"C:\Work\MyApplication\Release\MyApplication_test.exe" /MANIFEST /NXCOMPAT /PDB:"C:\Work\MyApplication\Release\MyApplication _test.pdb" /DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" "C:\Work\Speedsim30\Release\MyApplication_Controller.lib" /LTCG:STATUS /MACHINE:X86 /OPT:REF /SAFESEH /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"Release\MyApplication_test.exe.intermediate.manifest" /OPT:ICF /NOLOGO /TLBID:1
My personal computer has a powerful hardware configuration with Intel i7-4770K, 8 GB of DDR3-2133, and 2 SSDs in RAID0
thank you in advance
I found out that the problem is in in /MT and /MD mismatch between the library and the executable - i must have misclicked while setting up the release configuration. Correcting it allowed application to build.
When two visual studio processes compile in parallel, the second will reuse the instance of mspdbsrv started by the first one. So when the first build is terminated and the whole process tree terminated (e.g. by Jenkins), the other build fails.
That bug report describes how to start it manually so it does not get killed. But the thing is also famous for occasionally forgetting to close files, which can fail the next build.
Is there a combination of options under which mspdbsrv would not be used at all?
Ok, I am looking for a generic answer, so I didn't include the current options at first. But the answer so far sounds like mspdbsrv shouldn't be used when some options are not used. Except in the trivial test project used (by CMake) to check whether MSC++ works they are not used, yet it does start mspdbsrv.exe. The trivial projects is a .vcproj file, compiled via devenv.com CompilerIdC.vcproj /build Debug. The build runs following commands for C:
cl.exe /Od /D "_UNICODE" /D "UNICODE" /FD /EHsc /RTC1 /MDd /Fo"Debug\\" /Fd"Debug\vc90.pdb" /W0 /c /TC ".\CMakeCCompilerId.c"
link.exe /OUT:".\CompilerIdC.exe" /INCREMENTAL:NO /MANIFEST /MANIFESTFILE:"Debug\CompilerIdC.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /NODEFAULTLIB:"libc" /SUBSYSTEM:CONSOLE /DYNAMICBASE /NXCOMPAT kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib ".\Debug\CMakeCCompilerId.obj"
mt.exe /outputresource:".\CompilerIdC.exe;#1" /manifest ".\Debug\CompilerIdC.exe.intermediate.manifest"
and following commands for C++:
cl.exe /Od /D "_UNICODE" /D "UNICODE" /FD /EHsc /RTC1 /MDd /Fo"Debug\\" /Fd"Debug\vc90.pdb" /W0 /c /TP ".\CMakeCXXCompilerId.cpp"
link.exe /OUT:".\CompilerIdCXX.exe" /INCREMENTAL:NO /MANIFEST /MANIFESTFILE:"Debug\CompilerIdCXX.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /NODEFAULTLIB:"libc" /SUBSYSTEM:CONSOLE /DYNAMICBASE /NXCOMPAT kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib ".\Debug\CMakeCXXCompilerId.obj"
mt.exe /outputresource:".\CompilerIdCXX.exe;#1" /manifest ".\Debug\CompilerIdCXX.exe.intermediate.manifest"
This still starts the mspdbsrv.exe. I actually used the fact that it does to protect it from Jenkins killer for the time being.
The option /FD is injected by devenv.com. I've tried to run it via msbuild, but that invokes vcbuild (Visual Studio 2008) and that executes the same commands including the /FD option. And the WinCE targets are only supported by the Visual Studio generators in CMake, so I can't switch to make easily.
This is not a common complaint, there's no existing feedback report for it on connect.microsoft.com. Otherwise the recommended way to accelerate resolution of problems like this, you do get a Microsoft engineer to look at the issue.
And no, there is no specific option to disable mspdbsrv.exe. There is only one for the opposite, to enable it. The /FS option forces the compiler to use it.
Strong hints that you are using a compiler option that's not commonly used on build machines. You did not document anything so guessing is required. The number one candidate is the /MP option. Which always requires the compiler to use mspdbsrv.exe since it will launch the compiler multiple times, each working on one of the source files that were passed. A scenario where mspdbsrv.exe is required since each compiler instance is likely to want to write to the same .pdb file, particularly the program database specified in the /Fd option.
So look at your build scripts and remove /MP if you see it. Document the options you pass to the compiler next. Filing a feedback report at connect.microsoft.com is strongly recommended.
After update: your build server is using the /FD option incorrectly. The MSDN Library article has this to say about it:
/FD is only used by the development environment, and it should not be used from the command line or a build script.
I cannot predict what effect it has on mspdbsrv.exe, it very likely has one since /FS is strongly linked to /Gm which is strongly linked to /FD. Removing the option is the obvious next step.
I am sure you must already have tried setting "Generate Debug Info" -> No
Not sure if below came to your mind or not:
Try removing (or rename or move to other location) mspdbsrv.exe and related dlls (mspdb80.dll and mspdbcore.dll) and then see what happens.
This is just a wild guess but worth trying.
This is the output I get from dumpbin AchievementsTable.obj /HEADERS
Microsoft (R) COFF/PE Dumper Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file AchievementsTable.obj
File Type: ANONYMOUS OBJECT
ANON OBJECT HEADER VALUES
1 version
14C machine (x86)
4C51334D time date stamp Thu Jul 29 08:52:45 2010
ClassID: {0CB3FE38-D9A5-4DAB-AC9B-D6B6222653C2}
945F size
0 flags
ALL my source does this. I am using VisualStudio 2005. I know for a fact that there are lots of COMDATs being exported, as the .exe subsequently links and executes correctly: are there compiler switches I should be avoiding? Here are the ones I am using:
/O1
/Ob2
/Oi
/GT
/GL
/I "..\dxsdk\include" <lots of include paths>
/D "WIN32" <lots of #defines>
/GF
/FD
/MT
/GS-
/Gy
/arch:SSE2
/fp:fast
/GR-
/Fo <directory specified>
/Fd <pdb filename specified>
/FR <directory specified>
/W4
/c
/Zi
/TP .\Source\databases\AchievementsTable.cpp
I'm open to commentary on my selection in general, but DumpBin use is the focus of this question: take it away, boys and girls...
After a day of elimination, I discovered that the DUMPBIN documentation is a little ambiguous.
Switching on function level linking (/Gy) is needed to get the COMDAT output. Switching on cross module optimisations (/GL) delays code generation to link time. Therefore, although it is true that header information is available to code compiled with /GL, it is very limited. That's why it's the only option available to DUMPBIN - all the other options require more information, the generation of which is delayed by /GL.