MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015381CMakeCMakepublic2015-01-29 02:592015-11-02 09:13
ReporterØyvind Jensen 
Assigned ToBrad King 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
Platform64-bitOSWindowsOS Version7
Product VersionCMake 3.1.1 
Target VersionCMake 3.3Fixed in VersionCMake 3.3 
Summary0015381: VS: Map Intel Fortran flags for OpenMP, Traceback, and FloatingPointExceptionHandling
DescriptionUnknown flags are at risk of being unintentionally overwritten.

By "unknown flags" I mean: compile flags that are unknown to the Visual Studio generator, and for that reason are placed under "Additional options" in the source file properties dialog of Visual Studio.

According to the documentation, the COMPILE_FLAGS property represents *additional* flags. However, if an unknown flag is added to a source file using set_source_files_properties(... COMPILE_FLAGS ...),
any existing unknown flags will be overwritten.
Steps To ReproducePlease find attached a minimal case that reproduces this behaviour. The archive contains the files:
    cmake_bug_case/CMakeLists.txt
    cmake_bug_case/source.f90

1) Generate the build files using the Visual Studio 2010 generator (32bit or 64bit).

2) Verify that the "Additional options" field of the source file's property dialog (Configuration Properties -> Fortran -> Command Line) contains only the option "/unknown_flag2".

The expected outcome is to see both of the flags "/unknown_flag1" and "/unknown_flag2" in the "Additional options" field.

Additional InformationThere are some relatively important flags that are affected by this, for example the /Qopenmp and the /traceback flags of Intels fortran compiler.

The NMake generator does not have this problem. It behaves as one would expect from the documentation.

It is also interesting to note that if the COMPILE_FLAGS property is populated with options that are known to the VS10 generator (flags that do not end up in the "Additional options" field), everything works as expected.

Also, as you can see from the supplied test case, the problem is not that the COMPILE_FLAGS property is overwritten, but rather that the visual studio generator fails to combine compile flags with different origins.

CMake 2.8.12 has the same problem.
Tagsfortran, visual studio 2010, vs2010
Relationships
Attached Fileszip cmake_bug_case.zip (665) 2015-01-29 02:59
https://public.kitware.com/Bug/file/5370/cmake_bug_case.zip
patch 0001-VS-Add-more-Fortran-compiler-flags-to-flag-table.patch (1,567) 2015-03-06 04:49
https://public.kitware.com/Bug/file/5397/0001-VS-Add-more-Fortran-compiler-flags-to-flag-table.patch
zip test_case_fortran_flags.zip (457) 2015-03-06 04:52
https://public.kitware.com/Bug/file/5398/test_case_fortran_flags.zip
Issue History
Date ModifiedUsernameFieldChange
2015-01-29 02:59Øyvind JensenNew Issue
2015-01-29 02:59Øyvind JensenFile Added: cmake_bug_case.zip
2015-02-02 01:35Øyvind JensenTag Attached: visual studio 2010
2015-02-02 01:36Øyvind JensenTag Attached: vs2010
2015-02-02 01:37Øyvind JensenTag Attached: fortran
2015-02-03 14:39Brad KingNote Added: 0037895
2015-02-23 04:45Øyvind JensenNote Added: 0038017
2015-02-23 07:41Øyvind JensenNote Added: 0038018
2015-02-23 09:46Brad KingNote Added: 0038022
2015-02-24 04:50Øyvind JensenNote Added: 0038045
2015-02-24 10:07Brad KingNote Added: 0038051
2015-03-02 01:18Øyvind JensenNote Added: 0038100
2015-03-02 09:49Brad KingNote Added: 0038135
2015-03-06 04:49Øyvind JensenNote Added: 0038156
2015-03-06 04:49Øyvind JensenFile Added: 0001-VS-Add-more-Fortran-compiler-flags-to-flag-table.patch
2015-03-06 04:52Øyvind JensenFile Added: test_case_fortran_flags.zip
2015-03-06 04:55Øyvind JensenNote Added: 0038157
2015-03-06 15:58Brad KingNote Added: 0038171
2015-03-06 15:58Brad KingAssigned To => Brad King
2015-03-06 15:58Brad KingStatusnew => assigned
2015-03-06 15:58Brad KingTarget Version => CMake 3.3
2015-03-09 02:44Øyvind JensenNote Added: 0038178
2015-03-09 10:40Brad KingNote Added: 0038186
2015-03-09 10:41Brad KingStatusassigned => resolved
2015-03-09 10:41Brad KingResolutionopen => fixed
2015-03-09 10:41Brad KingFixed in Version => CMake 3.3
2015-03-09 10:41Brad KingSummaryCertain COMPILE_OPTIONS are missing in Fortran VS10 project after set_source_files_properties() => VS: Map Intel Fortran flags for OpenMP, Traceback, and FloatingPointExceptionHandling
2015-03-09 10:41Brad KingNote Added: 0038187
2015-03-10 08:41Brad KingNote Added: 0038197
2015-11-02 09:13Robert MaynardNote Added: 0039726
2015-11-02 09:13Robert MaynardStatusresolved => closed

Notes
(0037895)
Brad King   
2015-02-03 14:39   
One can see that the generated .vfproj file has the target-wide options set:


 <Tool Name="VFFortranCompilerTool" AdditionalOptions=" /W1 /unknown_flag1" ...>

and later the per-file options set:

 <FileConfiguration Name="Debug|Win32">
   <Tool Name="VFFortranCompilerTool" AdditionalOptions="/unknown_flag2" Optimization="optimizeMinSpace"/>
 </FileConfiguration>

When the same thing is done with VCCLCompilerTool in a C project (.vcproj in VS 2008) then both options appear. This appears to be a bug in VFFortranCompilerTool in the Intel Fortran plugin itself. I do not see any way, even through the IDE, to refer to the target-wide options in the value of the per-source options. In a .vcxproj file CMake already uses %(AdditionalOptions) to do this, but it does not seem to work in a .vfproj file.
(0038017)
Øyvind Jensen   
2015-02-23 04:45   
Thanks, you are right.

In VS2010 I see that for C/C++ projects there is a tick box immediately above the Additional Options field that reads "Inherit from parent or project defaults". Fortran projects, on the other hand, have no such tick box. It seems that Additional Options are inheritied from the project settings only if no source file specific Additional Options are set.

I'll ask Intel's support if they have plans to implement inheritance of Additional Options similar to how it works for C/C++.

Meanwhile, I think there is a quick fix that will at least relieve some of the pain: By adding more flags to CMake's list of known Visual Studio options, it may be possible to reduce the reliance on the Addional Options field. Although this will not resolve the issue properly, it will reduce the impact of the problem to a smaller set of compile flags.
(0038018)
Øyvind Jensen   
2015-02-23 07:41   
Here is my post on Intel's forum: https://software.intel.com/en-us/forums/topic/541948 [^]
(0038022)
Brad King   
2015-02-23 09:46   
Re 0015381:0038017: Thanks. Yes, adding more flag mappings can mitigate this issue. The current flag table is here:

 http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmLocalVisualStudio7Generator.cxx;hb=v3.1.3#l361 [^]

what more options do you need mapped?
(0038045)
Øyvind Jensen   
2015-02-24 04:50   
To me, the single most important flag is /Qopenmp.

Other important flags are:

/check:all
/check:noarg_temp_created
/fpe:0
/traceback

These are important because they should be used in Debug configuration, but not in Release. I have not been able to accomplish that, because of the issue with the AdditionalOptions. (I cannot simply add CMAKE_Fortran_FLAGS_DEBUG to the source file's COMPILE_OPTIONS_DEBUG property, because that property does not exist.)
(0038051)
Brad King   
2015-02-24 10:07   
Re 0015381:0038045: Okay. If you add those settings by hand in the IDE and save the project, then look at the .vfproj file. You should be able to construct a patch to add the proper mappings to the flag table I linked in 0015381:0038022.
(0038100)
Øyvind Jensen   
2015-03-02 01:18   
Thanks, I'll give it a shot.
(0038135)
Brad King   
2015-03-02 09:49   
Re 0015381:0038100: Great, thanks. If it turns into any more work than just adding a few table entries, please ask back here before trying to update the flag parser capabilities.
(0038156)
Øyvind Jensen   
2015-03-06 04:49   
Here is a patch that brings better support for

/Qopenmp[-stubs]
/fpe:[013]
/[no]traceback

It turned out that the /check family of arguments is more complex. In VS, the runtime check settings "All" and "None" trumps any other runtime check settings. OTOH, at the command line the later /check:* options take precedence. This difference means that if the CMakeLists.txt specifies e.g.

  COMPILE_OPTIONS="/check:all /check:nouninit",

the .vfproj file equivalent would need to explicitly list all activated checks. It is probably much cleaner to just leave the /check:* options for the AdditionalOptions field.
(0038157)
Øyvind Jensen   
2015-03-06 04:55   
I also uploaded a test case where the flags are used, both as target properties and as source file properties.
(0038171)
Brad King   
2015-03-06 15:58   
Re 0015381:0038157: Great, thanks. It looks good at a glance. I'll look at integrating it soon.
(0038178)
Øyvind Jensen   
2015-03-09 02:44   
Thanks, Brad!
(0038186)
Brad King   
2015-03-09 10:40   
Re 0015381:0038157: Applied, thanks:

 VS: Add more Fortran compiler flags to flag table
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7fde9794 [^]
(0038187)
Brad King   
2015-03-09 10:41   
Re 0015381:0038186: I've updated the summary to reflect the part of this issue that can actually be fixed and is addressed by your patch.
(0038197)
Brad King   
2015-03-10 08:41   
Re 0015381:0038186: I've revised the commit to add missing initializers that some compilers warned about:

 VS: Add more Fortran compiler flags to flag table
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=18d5a4bc [^]
(0039726)
Robert Maynard   
2015-11-02 09:13   
Closing resolved issues that have not been updated in more than 4 months.