Ability to identify flang by preprocessor

[ChrisTX]

Ability to identify flang by preprocessor

[jeffhammond]

Preprocessor symbols are the wrong way for CMake to detect the compiler identity and just about anything else. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016#c4 for an example where preprocessor symbols are intentionally wrong. If CMake needs to know if -Mipa=fast is valid, CMake should attempt to use it. This is how Autotools detects compiler support, which is the Right Way to do it.

Note also that preprocessing is not standard Fortran, so the entire premise of https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/CMakeFortranCompilerId.F.in is invalid. See http://fortranwiki.org/fortran/show/Preprocessors for details.

[jeffhammond]

Having supported Autotools projects with IBM, Cray, Intel, PGI, PathScale, GNU, and other vendor support for years, I know your description isn't accurate, but I'm not going to bother debating it here.

[nncarlson]

I'm not going to defend the way CMake determines compiler identity, but it is the way it is, and it is awfully hard to get those folks to change direction. That aside, is it appropriate that flang defines __PGIC__ ? Suppose I have some compiler bug workaround implemented for flang and I want to use a preprocessor variable to enable it? It looks like I'm using __PGIC__, but flang and the PGI compiler aren't the same thing anymore, are they?

[ChrisTX]

Except for the fact that -Mipa=fast does not result in an error with flang, it's just not recognized and creates a warning. In order to recognize this you would need to implement a way to detect if any compiler spits out a warning.

Quite literally, in order to know which set of flags can make sense for any compiler across platforms, CMake needs to sniff the compiler identity. You can't compare this to what autotools does - it expects a compiler to obey F77/FC semantics like gfortran does. Namely, it expects '-O2 -g' to work with a given compiler, and sets that as the default. CMake supports optimizations like IPO, which autotools does not outside of passing '-flto' (for GCC) in flags. If you want to create a system that's more contrived than just passing '-O2' for optimization or even grant the project the freedom to add specific flags for specific compilers, you're out of luck with autotools.

Furthermore, what you linked is unrelated to what CMake does. CMake detects the compiler identity and version, and not anything else. This is done by sniffing specific, compiler-specific identities - not by sniffing standard macros. Such macros are unreliable, but so far, outside of flang, I'm not aware of any C/C++/Fortran compiler CMake would fail to detect properly.

Lastly, preprocessing might not be standard Fortran, but CMake supports virtually all Fortran compilers on the market (Intel, GCC, G95, Absoft, NAG, PGI, IBM, Oracle/SunPro, ...) and on each of those this method works reliably to detect the compiler and its version. At the moment, no major compiler - certainly none listed in the Fortran Forum reports - wouldn't work this way. For practical purposes it doesn't matter at all whether it's standard or not as long as there is a way to work with it anywhere. As argued before, a system like CMake has not alternative to this process unless it drops to primitive assumptions on the compiler like autotools does.

[mleair]

This issue is now fixed in the commit mentioned above.