From owner-sc22wg5@open-std.org Thu Dec 4 05:39:24 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 41707CA5FE7; Thu, 4 Dec 2008 05:39:24 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from smtp.llnl.gov (nspiron-3.llnl.gov [128.115.41.83]) by www2.open-std.org (Postfix) with ESMTP id 1E1A6C56CF8 for ; Thu, 4 Dec 2008 05:39:21 +0100 (CET) X-Attachments: None Received: from vpna-user-128-15-244-72.llnl.gov (HELO [128.15.244.72]) ([128.15.244.72]) by smtp.llnl.gov with ESMTP; 03 Dec 2008 20:39:20 -0800 Message-ID: <49375EF7.6060503@llnl.gov> Date: Wed, 03 Dec 2008 20:39:19 -0800 From: Aleksandar Donev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.8) Gecko/20071009 SeaMonkey/1.1.5 MIME-Version: 1.0 To: WG5 Subject: Re: (j3.2006) (SC22WG5.3707) [ukfortran] Ballot on the technical content of the TR References: <20081127193527.EF00DC178D9@www2.open-std.org> <49360D4C.1020600@llnl.gov> <20081203121945.E7DEDC4596C@www2.open-std.org> In-Reply-To: <20081203121945.E7DEDC4596C@www2.open-std.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@open-std.org Precedence: bulk On Wednesday 03 December 2008 04:19, N.M. Maclaren wrote: > 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. Please specify exactly what "enough information" encompasses? Types containing ALLOCATABLE arrays (or pointers, or any other thing that is actually a descriptor inside the object) cannot be interoperable, and are not covered by N1761 by design decision. As to data conversion, that is beyond the Fortran standard. MPI does with its MPI_Datatype maps, and the user will still have to make those for derived types to tell MPI how to copy them among different machines or how to pack/unpack them or whatever. All the TR draft provides is the sizeof the struct, because it is the most useful and obvious thing. In many cases additional info will be needed, and the programmer has to pass that by mechanisms outside of the standard. > Fortran VALUE has nothing to do with the argument passing mechanism, > except in the current C interface. And except that it was added to Fortran in *support* of a C-like argument passing mechanism commonly used and commonly implemented in compiler extensions. Sure, someone (undoubtedly an academic) on WG5 decides it could be generalized and did it, but that has caused more problems than it is worth. > In particular, look at 12.5.2.3 > paragraph 4 for the extra semantics it defines, and why it is useful in > pure Fortran. It could be done in Fortran before and it can still be done, without a new attribute. Declare a temp, do an assignment yourself. No big deal. > Why do you WANT to exclude the combination, for arguments that are > necessarily NOT passed by value as C views it? Because for arguments that ARE passed by value as C views it, e.g., a simple one-word integer, many processors use passing conventions which is in direct conflict with what they do if VALUE is used. So, instead of forcing most everyone to massage conventions and thus re-introduce processor extensions/overheads, we simply eliminate a mostly useless functionality and limit the scope to allow more implementation flexibility without really giving up user needs (remember: I am a user). > 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. Do a grep of the standard. Anywhere it says assumed-shape, except for where it defined what assumed-shape means (fairly obvious places) and things explicitly specified as "except in .... these cases" in the TR (notably rules about rank matching), replace "assumed-shape" with "assumed-shape or assumed-rank". You will get the drift. I agree these details should be spelled out, but the vote here is on "technical content", to give guidance. I don't think anyone suggested this is ready for publishing. > > "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? But they do not become assumed-shape once they are allocated, so I don't get your point at all. > 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? Enough people in the group are casual or common users of C89/C99, and most are common users of Fortran. As such, they are the target group of the TR---the headers/tools from the TR are to be used by application programmers, not C99 experts. I agree that macros can be used to make the use of flexible array members almost painless. If we actually provide such macros and tell users how to use it, maybe it will be OK. I still find it distasteful, but maybe that is because I dislike most of C anyway... > You can allocate the space in several ways , including malloc and C99 > variable length arguments. It requires explicit memory management, leading to bugs. One cannot even declare such a descriptor on the stack. It complicates the most common, simple uses, just to allow flexibility for "future". > And the dereferencing is simple. But having an array member of fixed size is arguably *much* simpler. "simple" is an absolute term and thus depends on who is making the statement. The relative comparison, "simpler", is, I think, without argument. > 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? Because such an extension is outside the Fortran standard and that vendor can provide, along with the extension, an extension of the TR. Sorry, we don't support arbitrary-rank arrays, already. > 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; Using stack space and type casts seems acceptable, at least to me, as a user. If others agree, we can change the design to use flexible array members. BTW, are most/all compilers know C99-compatible, an in particular, do they support the features needed to make your proposal work? This was one of the considerations, as I recall, against using flexible array members. > > 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. OK, good you agree, but I still don't know what your point was, i.e., what you actually want. > 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. Does an existing Fortran compiler + C companion use thunking to pass interoperable structs? Is one planning to? How do compilers today handle changing the layout of structs on the C side? > There are many such standard practices in C. Why not choose one of the > ones that does not conflict with Fortran? It was a judgement call among several people. You/WG5 majority/UK delegation can disagree with it. I cannot make a technical argument unless I do surveys of users. > 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. Yes, we mean that on input the strides are ignored, and the routine calculates the correct strides and puts them in the descriptor, since the array is contiguous it knows how to do 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. It changes what Fortran sees. > If the former, then one statement is > wrong; if the latter, the other is. OK, now that we clarified, just tell us which statement is the problem and we will fix it. Best, Aleks