*ping* - Re: [Patch, Fortran] PR39505 - add support for !GCC$ attributes NO_ARG_CHECK

[Tobias Burnus]

Early *ping*.

For a usage, see for instance Open MPI, which since 1.7.0 uses it. From 
their trunk version:
http://svn.open-mpi.org/svn/ompi/trunk/config/ompi_fortran_check_ignore_tkr.m4
http://svn.open-mpi.org/svn/ompi/trunk/ompi/mpi/fortran/use-mpi-ignore-tkr/mpi-ignore-tkr-interfaces.h.in

Tobias


Tobias Burnus wrote:
> Minor patch update due to Janus' gfc_explicit_interface_required patch.
>
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
>
> Tobias
>
>
> Tobias Burnus wrote:
>> Minor patch update:
>> - Changed FAILURE to false due to Janne's patch
>> - Removed a left-over #if 0 debug code
>>
>> On Tobias Burnus wrote:
>>> Many compilers have some pragma or directive to disable the type, 
>>> kind and rank (TKR) checks. That feature matches C's "void*" pointer 
>>> and can be used in conjunction with passing some byte data to a 
>>> procedure, which only needs to know either the pointer address or 
>>> pointer address and size.
>>>
>>> I think the most useful application are MPI implementation. 
>>> Currently, the do not offer explicit interfaces for their procedures 
>>> which take a "void *buffer" argument. For MPI 3.0, many compiler 
>>> have started to use compiler directives which disable TKR checks - 
>>> and where gfortran is left out.
>>>
>>> The Fortran standard does not provide such a feature - and it likely 
>>> won't have one in the next standard, either. The Technical 
>>> Specification ISO/ICE TS 29113:2012 provides TYPE(*), which disables 
>>> the TK part of TKR. That's fine if one has either scalars or arrays 
>>> (including array elements) - then one can use "type(*) :: buf" and 
>>> "type(*),dimension(*) :: buf". But that doesn't allow for scalars 
>>> *and* arrays [1]. The next Fortran standard might allow for scalars 
>>> passed to type(*),dimension(*) in Bind(C) procedures - but seemingly 
>>> not for non-Bind(C) procedures nor is a draft in sight [2].
>>>
>>> (There is a possibility to pass both scalars and arrays to a dummy 
>>> argument, namely: "type(*), dimension(..)" but that uses not 
>>> directly the address but passes an array descriptor.)
>>>
>>> Other compilers have:
>>>
>>>   !DEC$ ATTRIBUTES NO_ARG_CHECK :: buf
>>>   !$PRAGMA IGNORE_TKR buf
>>>   !DIR$ IGNORE_TKR buf
>>>   !IBM* IGNORE_TKR buf
>>>
>>> With the attached patch, gfortran does likewise. I essentially use 
>>> the same mechanism as TYPE(*) with the code - after resolving the 
>>> symbol, I even set ts.type = BT_ASSUMED. Contrary to some other 
>>> compilers, which only allow the attribute for interfaces, this patch 
>>> also allows it for Fortran procedures. But due to the TYPE(*) 
>>> constraints, one can only use it with C_LOC or pass it on to another 
>>> NO_ARG_CHECK dummy.
>>>
>>> By the way, the recommended data type with this feature is TYPE(*). 
>>> In order to increase compatibility with other codes, it also accepts 
>>> intrinsic numeric types (and logical) of any kind.
>>>
>>> Build and regtested on x86-64-gnu-linux.
>>> OK for the trunk?
>>>
>>> Tobias
>>>
>>> [1] Generic interfaces are not really a solution as one needs one 
>>> per rank, i.e. scalar+15 ranks = 16 specific functions; with two 
>>> such arguments, up to 16*16 = 256 combinations. As other compilers 
>>> support directives and as, e.g., MPI has many interfaces, MPI 
>>> vendors won't go that route. However, I assume that they will start 
>>> using gfortran's dimension(..) at some point, in line with MPI 3. 
>>> Either the 4.8+ one with gfortran's current descriptor or the one 
>>> from Fortran-Dev.
>>>
>>> [2] Even if a first draft were available, one had to wait until at 
>>> least the first J3/WG5 vote to be _reasonable_ sure that the 
>>> proposal is in and won't be modified.
>>
>