From owner-sc22wg5@open-std.org Wed Dec 3 13:19:45 2008 Return-Path: X-Original-To: sc22wg5-dom7 Delivered-To: sc22wg5-dom7@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id B9D22C4596D; Wed, 3 Dec 2008 13:19:45 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by www2.open-std.org (Postfix) with ESMTP id 2964CC4596C for ; Wed, 3 Dec 2008 13:19:43 +0100 (CET) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:55581) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:nmm1) id 1L7qhj-0008BS-3h (Exim 4.70) for sc22wg5@open-std.org (return-path ); Wed, 03 Dec 2008 12:19:43 +0000 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1L7qhj-0000vG-4O (Exim 4.67) for sc22wg5@open-std.org (return-path ); Wed, 03 Dec 2008 12:19:43 +0000 Received: from [131.111.10.32] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 03 Dec 2008 12:19:43 +0000 Date: 03 Dec 2008 12:19:43 +0000 From: "N.M. Maclaren" To: WG5 Subject: Re: (j3.2006) (SC22WG5.3698) [ukfortran] Ballot on the technical content of the TR Message-ID: In-Reply-To: <49360D4C.1020600@llnl.gov> References: <20081127193527.EF00DC178D9@www2.open-std.org> <20081202130345.82E16C178E1@www2.open-std.org> <49360D4C.1020600@llnl.gov> X-Mailer: Prayer v1.3.1 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-sc22wg5@open-std.org Precedence: bulk Aleksandar Donev wrote: > > "It also does not support the most important > required interoperability aspects (e.g. (a) below). > a) the ability to call the MPI transfer functions with arrays > of interoperable derived types as choice arguments;" > --- > Can you please provide an example of what it is you want to do. The TR > is about calling Fortran routines with assumed-shape, allocatable or > pointer dummies from C. Or are you talking about TYPE(*). Being specific > will help understand the technical objection (as opposed to the general > "I will write a proposal that does it better", which I look forward to). All MPI choice arguments are arrays. Furthermore, MPI does not require all processes to use the same architecture, and supports data type translation across transfers. Unless I have completely misunderstood what it is proposing, N1761 does not provide the C with enough information to handle arrays of derived types, let alone derived types containing ALLOCATABLE arrays or data type conversion. > "5) The UK's requirement against N1763 for MPI support also needs > support for non-blocking and one-sided transfers, it was answered by > being referred to this proposed Technical Report" > --- > As you saw yourself, whoever answered you that way lied. There is > nothing in the TR about asynchronous data transfers. No, that's not right. The response wasn't that 08-305 did include it, but that UK requirement for MPI support be handled by the TR. No lying was involved - even though the response was misleading. > "Assumed-type variables > ---------------------- > There is no reason to exclude the VALUE attribute, as the C argument is > a pointer." > --- > Again, an example of what it is you want to see here would be useful. I > have no idea what it would mean to have VALUE and pass-by-address at the > same time. Fortran VALUE has nothing to do with the argument passing mechanism, except in the current C interface. In particular, look at 12.5.2.3 paragraph 4 for the extra semantics it defines, and why it is useful in pure Fortran. Why do you WANT to exclude the combination, for arguments that are necessarily NOT passed by value as C views it? > "Assumed-rank variables > ---------------------- > I do not know what the wording "In other respects, the rules for > assumed-rank dummy arguments are similar to those for assumed-shape > arrays" means, and whether it proposes any constraints on either the > processor or programmer." > --- > Of course, it poses all the constraints that assumed-rank arguments do. > These should be listed explicitly before this is made into a true TR > document. ... That should be done before it is circulated for comments on the details; at present, I cannot tell what it means so cannot comment on it. > 'Is the > type "struct CFI_desc_t" (as "struct tm" in time.h) or "CFI_desc_t" (as > "div_t" in stdlib.h)?' > --- > I believe the intention is that it be "struct CFI_desc_t" but I am not > sure what the pros and cons are so it should be discussed. Ugh. I do, and am happy to discuss a clearer proposal. > "does not allow assumed-shape arrays to be allocatable or pointers" > --- > Allocatable and pointer arrays are deferred shape---they are separate > from assumed-shape arrays. So I don't undestand. Not once they are allocated, surely? > "Why should assumed-shape but not assumed-rank be included together with > associated pointers and allocable variables?" --- You mean you want a > status value that says "this is an assumed-rank array"? Not necessarily. I am asking for a proposal that is clear enough that I can comment on such things. > "It is completely unnecessary for "dim" to be specified of being a fixed > length. C has the concept of a flexible array member as the last > element of a structure (C99 6.7.2.1, paragraph 16). That would enable > all of the references to CFI_MAX_RANK to be removed." > --- > Using flexible array members is horrendous. You have to malloc them, and > then the de-referencing is obnoxious. Much much less user friendly than > wasting a bit of memory and CFI_MAX_RANK. We discussed flexible array > members in subgroup and decided against it. I stand by that decision. That is completely wrong, for many, many reasons. How many people on that group were experts in C89, C99 and a wide range of interface conventions that use C? You can allocate the space in several ways , including malloc and C99 variable length arguments. And the dereferencing is simple. For example: CFI_array *ptr = (CFI_array *)malloc(offsetof(CFI_array,bounds)+ N*sizeof(CFI_bounds)); And the REALLY strong argument against binding fixed sizes into the specification is that it prevents later extension. 50 years of experience is that this is almost always a mistake. What about a Fortran compiler that doesn't impose any hard restriction on the number of dimensions? Why should a vendor be penalised for NOT writing old fashioned code? If you want a C89-compatible type to use for stack or static allocation, there are several ways that can be done cleanly (by C standards). Yes, they involve a cast. For example, by providing a macro: CFI_array_alloc(7) temp; CFI_array *ptr = (CFI_array *)temp; > "The types need to include a non-interoperable type, for use with > assumed-type arguments. The existing standard already allows them to be > passed between Fortran and C." > --- > Does it??? How? One can pass a C_LOC of a non-interoperable entity, but > it cannot be dereferenced in C, only passed back to Fortran. Precisely. > "The layout of C structures is very dependent on the compiler options. > In the existing Fortran standard, the processor can (in theory, at > least) remap structures." > --- > How is this different from BIND(C) types and whether they interoperate > with the corresponding C struct? The "companion" processor has to be a > good companion and not change layouts without the Fortran compiler > knowing that. That's not true. The Fortran compiler doesn't need to be told anything. All that is needed is that the thunking code knows what the two formats are. Been there; done that. > "Because they are C interfaces, that is > plausible, but it is undesirable to use a specification that conflicts > with Fortran's conventions." > --- > Well, either way, it will conflict with one convention (C standard > practice or Fortran). We chose to please the C people since they are the > most likely users of the interface. There are many such standard practices in C. Why not choose one of the ones that does not conflict with Fortran? > "CFI_update_fdesc is specified to use malloc, but that is an > unreasonable restriction on an implementation; the requirement should be > removed." > --- > This was only there so that free could be used without needing to > specify a separate "deletion" routine. It should be re-considered. Indeed it should. > 'CFI_allocate says "The supplied bounds override any current dimension > information in the descriptors. The stride values are ignored and > assumed to be one. Both the Fortran and C descriptors are updated by > this function." That makes no sense, as it would leave the descriptors > in an invalid state.' > --- > I don't get it, please explain what you mean. If you change the bounds without changing the stride, you will end up with an invalid descriptor. Doubtless you mean something different, but I have no idea what. > "Fortran has no concept of the strides of the actual arguments being > visible to the called procedure." --- But that is what we want to do > here, obviously. Please suggest new wording. The whole document needs rewriting, I am afraid. > '"The base address in the C descriptor for a data pointer may be > modified by assignment and that change later affected in the corresponding > Fortran descriptor by the CFI_update_fdesc function" means that > allocatable and pointer arrays can be changed other than by calls to > CFI_allocate and CFI_deallocate' > --- > Only pointers can be pointed by assigning the address. For allocatables > one has to use the provided allocation/deallocation routines. This is > because they may be automatically deallocated in the Fortran subroutine > and the compiler will use its own allocator for that. Fortran passes an INOUT POINTER array argument to C. The C descriptor contains the base address of the target. C changes that address and calls CFI_update_fdesc and returns. Either that changes the pointer as Fortran sees it or it does not. If the former, then one statement is wrong; if the latter, the other is. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1@cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679