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.