This is certainly OK for 4.8.
I have a couple of remarks:
(i) The DTYPE_TYPE_MASK is 0x38 so that we saturated it a long time
since! At the moment it does not cause any problems because of the
extremely limited use of the dtype 'type'. Whilst the array
descriptor revamp will eliminate such worries, we should be mindful of
(ii) By making such substantial use of scan-tree-dump-times in the
dg-run test case, you are potentially building in instability against
future development, I suppose? Are the runtime tests not sufficient?
Thanks for this early upgrade!
On Fri, Mar 2, 2012 at 12:28 PM, Tobias Burnus <bur...@net-b.de> wrote:
> TYPE(*) is Fortran's equivalent to C's "void *buffer". It may only be used
> for dummy arguments and essentially might only either be passed on, or
> appear in PRESENT, LBOUND/UBOUND/SHAPE/SIZE/IS_CONTIGUOUS - and most useful:
> in C_LOC.
> Note: For scalar TYPE(*) and for assumed-size dummies, only the address is
> passed on. But for dimension(:) and TS29113's new (but unimplemented)
> dimension(..) an array descriptor is passed. In that case, one might recover
> the type from the array descriptor - at least for intrinsic types.
> TYPE(*) is useful for, e.g., MPI (and used in the MPI v3 draft spec): There,
> one simply takes an argument of any type and transfers some bytes from it -
> without needing to know the type. TYPE(*) avoids to create hundreds of
> useless explicit interfaces for all kind of data types (and missing derived
> types that way) - or TS29113 avoids the alternative: Not using explicit
> interfaces (causing argument checking issues and prevents the use of
> See PR (or first test case) for a usage example. For a pure Fortran use, one
> could imagine:
> subroutine send(buf, size)
> use iso_c_binding, only: c_signed_char, c_size_t
> type(*) :: buf(*)
> integer(c_size_t) :: size
> integer(c_signed_char) :: ibuf(size)
> call c_f_pointer (c_loc(buf), ibuf, shape=[size])
> ! ... use ibuf ...
> [This example currently fails as "c_loc(buf)" is rejected. Several BIND(C)
> restrictions were removed in F2008 and especially in TS29113, but gfortran
> has not yet removed them.]
> For more details, see:
> * TS 29113 draft: ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1904.pdf
> (Status: Went as PDTR through one round of voting by the ISO members, was
> updated at the last J3 meeting and is now the subject of a one-month WG5
> ballot that ends on 19 March 2012. The schedule is that it will then be
> forwarded to SC22, which initiates a DTS ballot such that the final version
> will be published in September by ISO.)
> * MPIv3 draft (of 2011-12-15):
> Build and regtested on x86-64-linux.
> OK for the 4.8 trunk?
The knack of flying is learning how to throw yourself at the ground and miss.
--Hitchhikers Guide to the Galaxy