View Issue Details [ Jump to Notes ] [ Print ]
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.
Attached Files

 Relationships

  Notes
(0032131)
Brad King (manager)
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 (manager)
2013-06-03 09:05

 Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2013-01-22 19:30 Todd Greer New Issue
2013-01-23 11:34 Brad King Note Added: 0032131
2013-01-23 11:34 Brad King Assigned To => Brad King
2013-01-23 11:34 Brad King Status new => resolved
2013-01-23 11:34 Brad King Resolution open => fixed
2013-01-23 11:34 Brad King Fixed in Version => CMake 2.8.11
2013-01-23 11:34 Brad King Target Version => CMake 2.8.11
2013-06-03 09:05 Robert Maynard Note Added: 0033189
2013-06-03 09:05 Robert Maynard Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team