From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Fri Oct 28 01:27:07 2011 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 25FF13568F7; Fri, 28 Oct 2011 01:27:07 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.106]) by www.open-std.org (Postfix) with ESMTP id 6B9713568F5 for ; Fri, 28 Oct 2011 01:27:03 +0200 (CEST) Received: from [137.79.7.57] (math.jpl.nasa.gov [137.79.7.57]) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id p9RNQwGZ004281 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified NO); Thu, 27 Oct 2011 16:26:59 -0700 Subject: Re: (j3.2006) (SC22WG5.4575) Comments on N1885 From: Van Snyder Reply-To: Van.Snyder@jpl.nasa.gov To: "longb@cray.com" , sc22wg5 In-Reply-To: <4EA9CB87.1000505@cray.com> References: <1319512507.24176.553.camel@math.jpl.nasa.gov> <20111026183501.40C213568E1@www.open-std.org> <4EA9CB87.1000505@cray.com> Content-Type: text/plain Organization: Yes Date: Thu, 27 Oct 2011 16:26:58 -0700 Message-Id: <1319758018.24176.723.camel@math.jpl.nasa.gov> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-19.el5) Content-Transfer-Encoding: 7bit X-Source-IP: math.jpl.nasa.gov [137.79.7.57] X-Source-Sender: Van.Snyder@jpl.nasa.gov X-AUTH: Authorized Sender: owner-sc22wg5@open-std.org Precedence: bulk On Thu, 2011-10-27 at 14:22 -0700, Bill Long wrote: > Thanks, Van, for carefully reading through the draft. Responses for some > of your observations: > > On 10/26/11 1:34 PM, Van Snyder wrote: > > > > I have a few (possibly misguided) comments on N1885. > > 5.4.2p1: It seems to be OK for a processor to decide that > > pure real function xyz ( x ) > > integer, intent(in) :: x > > xyz = x + 1.0 > > end function xyz > > is an asynchronous communication initiation or completion procedure. > > > > So, you are saying that the description is too vague? It says "whether a procedure is... is processor dependent" That seems to allow the processor to decide either way. I thought it should have said nothing, or that the program determines whether a procedure is an asynchronous communication initiation or completion procedure, but Malcolm argued against this proposition. I don't know how to say that the processor might have a list of procedures that it knows to be asynchronous communication initiation or completion procedures, and that it somehow knows that a Fortran (or C) procedure that calls ... that calls (a dozen levels down) one of the procedures on the list is also an asynchronous communication initiation or completion procedure, and that no others are. If the processor is free to determine that the procedure in the example is an asynchronous communication initiation or completion procedure, all procedures might as well be asynchronous communication initiation or completion procedures... so why say anything at all? > > 6.4.1p1: I don't understand how the expression can work. Bill didn't comment on this one. I don't understand how the result can include the final element, size(array,rank(array),kind), if array is assumed size. > > 6.4.3p1: After "result" insert "of UBOUND(ARRAY,RANK(ARRAY),[KIND])". Bill didn't comment on this one. I assume the result only has the described value in the case commented here. > > 8.3.5.3p7: The example would be more informative if the bounds were > > different. Inquiring minds might realize that Fortran and C bounds > > have opposite ordering, and wonder which order they ought to appear in > > the lower and upper arrays. > > > > The upper bounds are already different (100 and 1000). Would 100 and 500 > be better? Yeah, 100 and 500 would be better. I obviously looked at it quickly and saw 100 twice. > > 8.3.5.5 generally: It's not obvious how to establish an assumed-length > > character scalar. > > > > Do you mean one for which the length is deferred? I was thinking of the need to describe an actual argument that will become associated with a dummy argument that is an assumed-length character scalar. Something like "char c[42];" being passed to "character(len=*,kind=c_char) :: c" 8.3.5.5p3 says it's possible, but it's not obvious how. This could probably be addressed by an example. It would be helpful to include "assumed length" or "assumed length character" in Table 8.1 and 8.3.4p6. > > 8.3.5.7p2, description of "lower_bounds" and "upper_bounds": Is the > > order of elements in the arrays the order of C array bounds or Fortran > > array bounds? What is "the given array?" Should this be "the array > > described by the descriptor dv?" Is it OK for the number of elements > > to be > source->rank? > > > No. But, in C it is not clear how you would ever know. The C program might not know, but the C programmer could know just by looking at the text of the program. C programmers can't designate an array section with the lbound:ubound Fortran notation, so one might be tempted to conclude that it is actually necessary that the argument has the specified extent. i.e., CFI_index_t lower_bounds[5]; can't be an argument if the "rank" member of "source" is not exactly 5. It seems to be harmless if there are more elements in the array; the procedure just doesn't look at them, so they don't even need to have defined values. The same reasoning applies to arguments of other functions that are described as having an array for which it says "the number of elements shall be source->rank" instead of "the number of elements shall not be less than source->rank". > > 8.3.5.8p2: It's not obvious how (or even if it's possible) to select a > > substring of a character array. > > If it were not possible, the elem_len argument would not be part of the > formal parameter list. The displacement gives the offset from the > beginning of the character array element, and the elem_len gives the > length of the substring. The maximum size of the elem_len should > probably be source->elem_len - displacement*sizeof() for the type. An example would be helpful. > > 8.3.9p2,p3(1): "BIND" should be "BIND(C)" > > The name of the attribute is "BIND" (5.3.5 in F2008), and the text being > replaced in F2008 by this text currently says "BIND", so I disagree with > this. This question came to mind because of a remark I overheard at 196 concerning BIND things other than BIND(C), perhaps in Cray's compiler (or desired to be therein by Cray customers). IIRC, it was BIND(UPC).