[cmake-developers] [Feature Request] Fortran standards compliance for various compilers

[Christian Pfeiffer]

On 4/22/2017 7:33 AM, C Bergström wrote:

> On Thu, Apr 20, 2017 at 4:12 AM, Alan W. Irwin
> <irwin at beluga.phys.uvic.ca> wrote:
>> On 2017-04-19 07:27+0200 Rolf Eike Beer wrote:
>>
>>>> <Feature Request> What would really be useful is a list containing
>>>> what Fortran features from the Fortran 2003 and 2008 standards that the
>>>> given Fortran compiler supports.  That information is already
>>>
>>> To name the kid: this is about adding CMAKE_Fortran_KNOWN_FEATURES and
>>> friends, no?
>>
>> I wasn't aware of CMAKE_C_KNOWN_FEATURES and CMAKE_CXX_KNOWN_FEATURES,
>> but now that I have looked them up, I agree adding
>> CMAKE_Fortran_KNOWN_FEATURES is the right way to go rather than the
>> generic list I proposed above.
>>
>>> This exactly sounds like the whole compile_features things
>>> already done for C and C++, so yet another language shouldn't be too hard
>>> I
>>> guess.
>>
>> Especially since that Fortran information is already collected in
>> well-organized form in on one place, namely
>> <http://www.fortranplus.co.uk/app/download/23704631/fortran_2003_2008_compiler_support.pdf>.
> With my Fortran compiler vendor hat on - Please do be aware that this
> list of supported features may not be 100% accurate.
>
> #1 Vendors can add support that hasn't been reflected in that document
>
> #2 Not all claimed support is created equal. There's quite a few F2K3
> OO features that someone can claim to support, but when you start
> digging into real code they just flat out fail. (maybe less of the
> case now than it was before)
>
> #3 F2K8 aka CAF features could be supported, but may require
> additional runtime libraries or 3rd party software to actually work.
> For example our implementation ties to specific hardware and may not
> be 100% portable. Other implementations may depend on OpenMPI and not
> work with MPICH.
>
> I guess I'm saying that auto-detecting this stuff is cool, but do
> ensure that someone can easily override it. If as a vendor I say we
> support F2K8 and I'd like that enabled by default for supported
> versions of the compiler I really don't want to fight against some
> auto-test which might think otherwise.
>
>
> Thanks

I reckon working with the document is the most accurate option, though. 
It should be possible tooverride it somehow, since it can't be 
completely accurate nor updating outside of its 6-month cycle.
Coarrays need special treatment in CMake anyways. Right now, there's no 
way of determining which is the right way to enable Coarrays, if any.

Right now, in Intel Fortran, there's a number of related compiler 
switches, permitting anything from distributed to single image Coarrays, 
see https://software.intel.com/en-us/node/691534 .Each of these will 
also pull in different libraries that would need detection.

GFortran is even worse in this regard, since GCC 4.6, they've been able 
to support single images via -fcoarray=single, in GCC 4.7 they've got a 
barebones implementation using a communications library and since 5, 
that implementation is claimed to be "fully supported [...] except of 
bugs and incomplete support of special cases". Not to mention that GCC 
does not ship any useful communications library on their own, but rather 
relies on the external projects, see https://gcc.gnu.org/wiki/CoarrayLib 
, and can only support Coarrays in a useful fashion if an ABI compatible 
implementation like OpenCoarrays is installed on the system meaning 
feature completion also depends on some external library.

Either way, Coarrays should be the only feature in need of exceptional 
treatment, and for any other Fortran feature, it should be sufficient to 
work in a way comparable as to how C/C++ is being handled today.

- Chris