[Patch, Fortran] PR39505 - add support for !GCC$ attributes NO_ARG_CHECK

[Tobias Burnus]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: no_arg_check.diff
Type: text/x-patch
Size: 22440 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20130410/44e8ce11/attachment.bin>