View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0016094CMakeCMakepublic2016-05-05 01:572016-06-10 14:31
ReporterDamian Rouson 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSOS Version
Product VersionCMake 3.5.1 
Target VersionFixed in Version 
Summary0016094: CMake 3.5.1 misinterprets C preprocessor logic
DescriptionThe attached, reduced example demonstrates CMake's erroneous interpretation of compound conditional C preprocessor logic that wraps statements that handle dependencies in a Fortran project. The file shared/fft.F90 filed demonstrates the syntax that exposes the bug and an alternate but otherwise equivalent syntax that works correctly.

Damian
Steps To ReproduceSome of the compilation flags employed in the CMake scripts require the Intel C and Fortran compilers and Intel MPI.

tar xf missed_dependency.tar.bz2
cd missed_dependency
mkdir build
cd build
FC=mpiifort CC=mpiicc cmake ..

TagsNo tags attached.
Attached Filesbz2 file icon missed_dependency.tar.bz2 [^] (1,422 bytes) 2016-05-05 01:57

 Relationships

  Notes
(0041029)
Brad King (manager)
2016-05-05 10:38

 The key part of the example is:

> ! CMake misses the dependency of fft_mod on fft99_mod with the following
> ! C pre-processor conditional logic:
>
> #if defined(_CRAY) || defined(sgi_mipspro)
> # define SGICRAY
> #endif
>
> #ifndef SGICRAY
> # ifndef NAGFFT
> use fft99_mod, only: fft991, set99
> # endif
> #endif

CMake's dependency scanning does approximate preprocessing but does not have all the details that the compiler does. In this case it looks like it is missing the compiler-predefined platform-specific definition.

> ! CMake picks up the dependency correctly if the following syntax
> ! replalces the logically equivalent syntax above:
>
> !!$#if !(defined(SGICRAY) || defined(NAGFFT))
> !!$use fft99_mod, only: fft991, set99
> !!$#endif

I wonder if CMake's approximate parser is ignoring the preprocessor directives here because the look like different syntax.
(0041030)
Brad King (manager)
2016-05-05 10:40

 I do not think much can be done about this in CMake's parser currently. OTOH my work toward support for CMake+Ninja+Fortran uses the compiler's preprocessor first and then parses that output for the module dependencies. Perhaps that approach can be ported back to the Makefile generator, but it may be a non-trivial effort.
(0042998)
Kitware Robot (administrator)
2016-06-10 14:29

 Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

 Issue History
Date Modified Username Field Change
2016-05-05 01:57 Damian Rouson New Issue
2016-05-05 01:57 Damian Rouson File Added: missed_dependency.tar.bz2
2016-05-05 10:38 Brad King Note Added: 0041029
2016-05-05 10:40 Brad King Note Added: 0041030
2016-06-10 14:29 Kitware Robot Note Added: 0042998
2016-06-10 14:29 Kitware Robot Status new => resolved
2016-06-10 14:29 Kitware Robot Resolution open => moved
2016-06-10 14:29 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:31 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team