MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013867CMakeCMakepublic2013-01-22 19:302013-06-03 09:05
ReporterTodd Greer 
Assigned ToBrad King 
PrioritynormalSeveritymajorReproducibilityrandom
StatusclosedResolutionfixed 
PlatformVisual Studio 2010OSWindowsOS Version8
Product VersionCMake 2.8.10.2 
Target VersionCMake 2.8.11Fixed in VersionCMake 2.8.11 
Summary0013867: /Zm1000 flag triggers C1027 compiler failure in Visual Studio 2010
DescriptionI recently started encountering a C1027 compilation failure in a previously working Visual Studio 2010 project. Nominally, this means that there was a mismatch in my /Ym precompiled header settings, but there is no such mismatch. In fact, the failure happened with no changes to trigger it.

It appears that this is triggered by the /Zm1000 flag in the default CMAKE_CXX_FLAGS. I claim this for two reasons:

1. Removing that flag cured the compilation failure, which was happening repeatedly. (This appears to be the kind of issue that is difficult to reproduce, but, once reproduced, will continue to recur on that system for a while.)

2. There were other reports (such as [1]) of large /Zm flags causing this error in VS2010, with the suggested resolution of removing it or reducing it to a smaller value. (That's how I found the solution.)

I propose that for VS2010 and beyond, /Zm1000 should be removed. Microsoft says that "the /Zm compiler option is rarely necessary" [2] in VS2010. As a memory tuning parameter, it doesn't make sense for CMake to choose the value; it will naturally vary by computer and project. The worst-case consequence of removing it will be potentially causing a build to break, but it will break rarely, and in a very obvious way.

Additionally, searching for "CMake /Zm1000" shows several people having had to waste their time discovering why CMake builds with default settings weren't working. Yes, once you figure out what the problem is, the workaround (pulling it out CMAKE_CXX_FLAGS) is easy, but that only comes after hitting a build failure, finding reports that large /Zm settings can cause it, searching through your own files to see where you're setting it, finding that you aren't, searching the web to find out if CMake is setting it and how do override it, and finally finding the answer.

This flag has caused enough trouble for enough people to justify removal, particularly when it is of no clear value.

Thank you.
Steps To ReproduceIt is unclear how easy this is to reproduce. I think the best way is to compile the largest project you can find on a system with the smallest amount of memory you can give it.

My system is a Windows 8 Pro (64 bit) with 4GB of RAM (3.80 GB usable).
Additional Information[1] http://www.ogre3d.org/forums/viewtopic.php?f=2&t=60015&start=0 [^]
[2] http://msdn.microsoft.com/en-us/library/bdscwf1c%28v=vs.100%29.aspx [^]
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2013-01-22 19:30Todd GreerNew Issue
2013-01-23 11:34Brad KingNote Added: 0032131
2013-01-23 11:34Brad KingAssigned To => Brad King
2013-01-23 11:34Brad KingStatusnew => resolved
2013-01-23 11:34Brad KingResolutionopen => fixed
2013-01-23 11:34Brad KingFixed in Version => CMake 2.8.11
2013-01-23 11:34Brad KingTarget Version => CMake 2.8.11
2013-06-03 09:05Robert MaynardNote Added: 0033189
2013-06-03 09:05Robert MaynardStatusresolved => closed

Notes
(0032131)
Brad King   
2013-01-23 11:34   
This has been fixed recently here:

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cd739794 [^]
(0033189)
Robert Maynard   
2013-06-03 09:05   
Closing resolved issues that have not been updated in more than 4 months.