I have just upgraded Microsoft Visual Studio Enterprise 2015 from Update 2 to Update 3 and now I am getting the following error:
fatal error C1001: An internal error has occurred in the compiler.
(compiler file 'f:\dd\vctools\compiler\utc\src\p2\wvm\mdmiscw.c', line 2687)
To work around this problem, try simplifying or changing the program near the locations listed above.
Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information
The location is the first line which includes a header. The project has settings
/FR"x64\Debug\" /GS /W3 /Zc:wchar_t /Zi /Od /Fd"x64\Debug\vc140.pdb"
/Zc:inline /fp:precise /D "WIN32" /D "_DEBUG" /D "_WINDLL" /D
"_UNICODE" /D "UNICODE" /errorReport:prompt /WX- /Zc:forScope /clr
[some /FU"..."] /MDd /Fa"x64\Debug\" /EHa /nologo /Fo"x64\Debug\"
/Fp"....pch"
How do I make my project build again?
C1001 basically indicates a compiler crash, i.e. you might have created valid C/C++ code that triggers a bug in the VC compiler. It would probably be a good idea to submit a bug report via https://connect.microsoft.com/VisualStudio/Feedback for further investigation by Microsoft.
I myself just ran into a C1001 while compiling OpenCV with Visual Studio Express 2015 Update 3. In my case, the C1001 error message also pointed me to the OpenCV core code line that triggers the compiler crash. After looking into the actual code semantics at that particular line, I suspected the compiler's floating point handling to be the root cause of the issue. It was dealing with a big, hard-coded double array lookup table which might have caused rounding issues. (Just in case somebody googles for this, I am listing the reference here: opencv_core, mathfuncs_core.cpp, line 1261, macro-expansion of LOGTAB_TRANSLATE).
In my case, setting the compiler's floating-point model from 'precise' to 'strict' resolved the C1001 issue. However, as you haven't included a code fragment of the lines that cause the C1001 to raise, it's difficult to say whether the above will fix your issue as well. If you want to give it a try, you can find the compiler switch in your project settings / C/C++ / Code Generation tab. Instead of Precise (/fp:precise), select Strict (/fp:strict) as Floating Point Model. This change may affect the performance of your code, but should not affect its precision. See https://msdn.microsoft.com/en-us/library/e7s85ffb.aspx for further information.
According to visual studio developers community,
this issue was fixed and closed (on July 2019) and should not appear at latest VS version. So upgrading to the latest version should solve the issue.
However, I've just now upgraded my VS to the latest version (16.7.1) and I still encounter this problem getting fatal error C1001: Internal compiler error.
An edit: See the comments below, people say the issue also appears at VS 2022 17.3.6 and at VS 2019 16.9.4
Finally, the following solution worked for me:
change the optimization option (project properties->C/C++->optimization) to 'Custom' and at (project properties->C/C++->command line') add additional options of '/Ob2, /Oi, /Os, /Oy'.
taken from: Visual studio in stuck Generating code
Related
I try to compile a piece of code with:
cl /c /std:c++latest /Gm- /sdl /Zc:inline /RTC1 /Oy /MDd /FA /EHs main.cxx
but I get this error:
error C2039: 'any': is not a member of 'std'
and I wonder how (if possible) can I get to have this feature. I don't see anything about it on their sites but knowing how much time they take to update them maybe it can be done
Yes, <any> has shipped with every release of VS 2017.
It is, but one has to make sure that the correct c++ version is used.
Right click the project and under Properties->C/C++->Language->C++ Language Standard make sure it is set to the correct one.
We have ported a VS2013 C++/MFC application to VS2015 and are having some rather disturbing issues with the performance and code generated by the VS2015 compiler.
Note this is for x86.
It is magnitudes slower on log10() calls. When profiling a Release build using CPU sampling, we see that these calls take up a lot more time than they did before. Going from e.g. 49 samples on the same run for VS2013 to a whopping 7545 samples for the same run in VS2015. This means this function goes from 0.6% of CPU load to 50% for the application in question.
In VS2013 profiler shows:
Function Name Inclusive Samples Exclusive Samples Inclusive Samples % Exclusive Samples %
__libm_sse2_log10 49 49 0.61 0.61
In VS2015 profiler shows:
Function Name Inclusive Samples Exclusive Samples Inclusive Samples % Exclusive Samples %
___sse2_log102 7,545 7,545 50.43 50.43
Why a different function name?
We have looked briefly at the generated assembly for log10. On VS2013 this forwards to disp_pentium4.inc and log10_pentium4.asm. On VS2015 this is different. It seems VS2015 goes back to __libm_sse2_log10 in Debug.
Could the __sse2_log102 be the cause of this performance difference alone? We have checked that results output from functions calling these are within expected floating point differences.
We are compiling with target v140_xp and have the following compile options:
/Yu"stdafx.h" /MP /GS- /GL /analyze- /W4 /wd"4510" /wd"4610" /Zc:wchar_t /Z7 /Gm- /Ox /Ob2 /Zc:inline /fp:fast /D "WINVER=0x0501" /D "WIN32" /D "_WINDOWS" /D "NDEBUG" /D "_CRT_SECURE_NO_WARNINGS" /D "_CRT_SECURE_NO_DEPRECATE" /D "_SCL_SECURE_NO_WARNINGS" /D "_USING_V110_SDK71_" /D "_UNICODE" /D "UNICODE" /errorReport:prompt /WX- /Zc:forScope /GR /arch:SSE2 /Gd /Oy /Oi /MT
Also shown here when viewing properties:
All project settings are the same for both VS2013 and VS2015. Note we are using SSE2 and have floating point model set to fast.
Has anyone encountered the same issue and know how to fix this?
Here my comment as an answer.
It appears that VS2015 has changed the implementation of log10 in release builds, where it calls this new __sse2_log102 function instead of the old __libm_sse2_log10 and that this new implementation is the cause of a huge performance difference.
The fix for us in this case was to call an implementation available in Intels Performance Primitives (IPP) library. E.g. instead of calling:
return log10(v);
Call this instead:
double result;
ippsLog10_64f_A53(&v, &result, 1);
return result;
This resulted in the performance issue to disappear, in fact it was slightly faster using an old IPP 7.0 release. Not all can use and pay for IPP, though, so we hope Microsoft fixes this.
Below is the version of VS2015 that has shown this issue.
I turned off FPO manually(/Oy–) in vs2008 ,but it has no effect and my code still omits frame pointers in release version.
BTW i also turned off /GL as micosoft said there was a bug bwtween /GL and /O2 enter link description here
every thing was OK when i tried to compile the same project with vs2010, ,but i need to make it work in vs2008,does any one know how to fix this? thanks!!!
I'm currently working on an unmanaged Windows C++ application.
I'm new to the world of CMAKE and C++.
I'm also new to the world of this current unmanaged C++ application.
I'm trying to integrate DevPartner into my build to instrument the build for memory errors and runtime errors.
In order to build for instrumentation, I need to change to using the DevPartner compiler (nmcl.exe).
Additionally, I need to add compiler settings to the existing CXX_FLAGS for instrumentation.
How do I go about doing this?
For VS releases 2008 and earlier.... (Except VS6 it uses msdev)
Well digging more into cmake I will say this someone with more knowledge will be able to take this and run with it.
I did find that the CL and LINK commands really do nothing since this just kicks off Devenv for VS2003 to 2008 and MSBuild for VS2010. Changing CL to NMCL will not matter since MSBuild uses the targets files which is why my other answer needs the user files modified. And why we need to use another tool here.
Devenv called with /Build internally uses the project files to know what source files need to be built. It will then call createprocess internally to spawn CL and LINK as needed. This is why changing CL to NMCL in the cmake files is useless.
Luckily we have another tool that can be used here....
We need to change
//make program
CMAKE_MAKE_PROGRAM:FILEPATH=C:/Program Files (x86)/Common Files/Micro Focus/NMShared/CTI/11.1/NMdevenv.EXE
and
CMAKE_BUILD_TOOL:INTERNAL=e:/PROGRA~1/MICROS~2.0/Common7/IDE/devenv.com
to C:/Program Files (x86)/Common Files/Micro Focus/NMShared/CTI/11.1/NMdevenv.EXE
Now this is where someone with a little more knowledge is needed. We also need to pass the type of instrumentation to nmdevenv as the 1st parameters.
I believe it can be done something like this
set(CMAKE_MAKE_PROGRAM "${CMAKE_MAKE_PROGRAM} " /nmon")
One other issue here is that we need devenv to be in the path as well so the Path env variable will need to be set correctly as well. This can be done by running the correct vscvars bat file.
Hope this helps and if you are using vs2008 and previous please add the steps needed to what I started here. I am sure it will help other users in the long run. If I get some more time to investigate this I will find the way to do it.
Edit
Well I did manage to get this working with VS2008. I did have to make a change to our nmdevenv wrapper as cmake was trashing our SearchPath functionality.
Here is what I did.
Replaced the make program as above
Ran VCVars32
Ran cmake --build mytestproj
Ran the program under BounsChecker
Now I switched to pass in /nmtxon for performance profiling
This had me stumped for a bit as it kept compiling for Error Detection
And that is when I found this in the converted project files
<Tool
Name="VCCLCompilerTool"
AdditionalOptions=" /NMbcon /Zm1000"
Changed that to
and all is well. I had my performance compiled option.
So I went back and modified this line in the CMakeCache.txt file opened the GUI, configue, generate
//Flags used by the compiler during all build types.
CMAKE_CXX_FLAGS:STRING= /NMbcon /DWIN32 /D_WINDOWS /W3 /Zm1000 /EHsc /GR
Then the project was switched back to use /NMbcon. So that is the correct spot to put the switch if you want to compile all with us. Otherwise use the appropriate Debug or release line.
portion of Cmake output
Notice Instrumenting in the output
Microsoft (R) Visual Studio Version 9.0.30729.1.
Copyright (C) Microsoft Corp. All rights reserved.
1>------ Build started: Project: Test, Configuration: Debug Win32 ------
1>Compiling...
New Command line nmcl.exe /NMtxon #e:\cust\Test3\Test\Test.dir\Debug\RSP0000011
2568792.rsp /nologo /errorReport:queue
1>Test3.cpp
1>Instrumenting ..\Test3\Test3.cpp
1>Compiling manifest to resources...
1>Microsoft (R) Windows (R) Resource Compiler Version 6.1.7600.16385
1>Copyright (C) Microsoft Corporation. All rights reserved.
1>Linking...
In summary
Use Cmake to generate the CMakeCache.txt and directories
Modify CmakeCahe
Use NMDevenv as the MAKE program
Add /NMon switch to the flags
run CmakeGui and generate again
Run VCVars32
Run cmake --build file
Run the program under devpartner
Which version of Visual Studio are you using? That makes a fair amount of difference, as how the instrumentation is managed has changed over the years . . . not so much by version of DevPartner as by version of Visual Studio.
Not 100% sure for a cmake file but this is from an old VS 6 makefile modified for Devpartner. Perhaps you can post a relevant section of the makefile for me to look at.
/nmbcon is a compile flag that says use BC instrumentation /nmtxon would be used for coverage analysis
CPP=cl.exe
CPP_PROJ=/nologo /MD /W3 /Gm /GX /Zi /Od /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_WINDLL" /D "_AFXDLL" /D "_MBCS" /D "_AFXEXT" /Fp"$(INTDIR)\main.pch" /Yu"stdafx.h" /Fo"$(INTDIR)\" /Fd"..\bin\Debug\MAIN.pdb" /FD /GZ /c
Would become
CPP=nmcl.exe
CPP_PROJ= /nmbcon /nologo /MD /W3 /Gm /GX /Zi /Od /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_WINDLL" /D "_AFXDLL" /D "_MBCS" /D "_AFXEXT" /Fp"$(INTDIR)\main.pch" /Yu"stdafx.h" /Fo"$(INTDIR)\" /Fd"..\bin\Debug\MAIN.pdb" /FD /GZ /c
Oh and the other poster is correct things have greatly changed by version of Visual Studio. VS2010 changed the build process to use MSBuild this caused us to completely modify the way we intercept and instterument for VS2010 and 2012.
*EDIT
Well I did download and go through the pain of Cmake internship this morning. For VS2010 this seems to be a pretty simple modification just like would be needed for one of our users using MSBuild from the command line.
In the out dir "Where to build the binaries" after the first build there will be .vcxproj.user files. This is where you need to add the flags for instrumentation
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
<DevPartner_IsInstrumented>1</DevPartner_IsInstrumented>
<DevPartner_Instrumented_Type> /NMbcOn</DevPartner_Instrumented_Type>
</PropertyGroup>
</Project>
This can be a repeating section for each
that you wish to build.
The next key DevPartner_IsInstrumented tells us to instrument (1) or not (0).
The last key DevPartner_Instrumented_Type> is what type to instrumetnt /nmbcon (Boundschecker) /nmtxon (Performance or Coverage) or both keys passed.
So it could look like
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
<DevPartner_IsInstrumented>1</DevPartner_IsInstrumented>
<DevPartner_Instrumented_Type> /NMbcOn</DevPartner_Instrumented_Type>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
<DevPartner_IsInstrumented>0</DevPartner_IsInstrumented>
<DevPartner_Instrumented_Type> /NMbcOn</DevPartner_Instrumented_Type>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
<DevPartner_IsInstrumented>0</DevPartner_IsInstrumented>
<DevPartner_Instrumented_Type> /NMbcOn</DevPartner_Instrumented_Type>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
<DevPartner_IsInstrumented>1</DevPartner_IsInstrumented>
<DevPartner_Instrumented_Type> /NtxcOn</DevPartner_Instrumented_Type>
</PropertyGroup>
</Project>
which would be Boundschecker for Debug win32, nothing for Release win32, nothing for debug x64 and Performance / Coverage for release x64
If IsInstrumented 0 whatever is in the type will not matter as it will not be passed.
FYI if you open the solution in VS2010 and turn instrumentation on this will be added to the vcxproj.user files for you. And the instrumentation settings are by project / config as well.
If not using VS2010 my note below might be correct for those versions.
For full disclosure I am the lead developer on the instrumentation engine for DevPartner.
I am using Microsoft Visual Studio 2011 Professional Beta
I am trying to run the OpenCV C++ files (http://opencv.willowgarage.com/wiki/Welcome) that I have compiled using cMake & the Visual Studio Complier.
However when I go to debug the project I get 600+ errors most of them being:
error LNK2026: module unsafe for SAFESEH image.
Apparently these files are in the opencv_ffmpeg project but I couldn't find them, I have had a look at the safeseh Safe Exception Handlers page on the Microsoft help page but I couldn't find any definitive answers.
I was wondering if anyone else has had this problem and if they managed to fix it.
Disabling option "Image has Safe Exception Handlers" in Project properties -> Configuration Properties -> Linker -> Advanced tab helped me.
From the comments:
This happens when you link an .obj or .lib that contains code created by an earlier version of the compiler. Which of course would be common if you downloaded a binary for opencv_ffmpeg instead of the source. You can turn the linker option off but then you'll still have a CRT version incompatibility that can byte. Rebuild the library from source. – Hans Passant May 15 at 13:01
Thanks for the help, it worked – Aaron Thompson May 17 at 14:50
If you got this error while building ZLIB in Visual Studio here is the solution. Look for contrib\masmx86\bld_ml32.bat and add /safeseh as a option
Before
ml /coff /Zi /c /Flmatch686.lst match686.asm
ml /coff /Zi /c /Flinffas32.lst inffas32.asm
After
ml /safeseh /coff /Zi /c /Flmatch686.lst match686.asm
ml /safeseh /coff /Zi /c /Flinffas32.lst inffas32.asm
Other way is to add some SEH handler (empty for example) to asm files and compile them with /safeseh option, then compile other code normally with /SAFESEH:YES compiler option.
Empty SEH handler:
.safeseh SEH_handler
SEH_handler proc
;handler
ret
SEH_handler endp
Your mileage may vary, but none of the above suggestions worked for me (although I did not try rolling my own asm exception handler).
What did work was to select build target Release/x64.
I am running Windows 10 on a 64-bit machine, and using Visual Studio 2015.
The target Release/Win32 works, too. I guess the main thing is to pick "Release".