From owner-sc22wg5@open-std.org  Wed Mar 30 19:40:47 2011
Return-Path: <owner-sc22wg5@open-std.org>
X-Original-To: sc22wg5-dom8
Delivered-To: sc22wg5-dom8@www2.open-std.org
Received: by www2.open-std.org (Postfix, from userid 521)
	id 18F10C3BA00; Wed, 30 Mar 2011 19:40:47 +0200 (CET DST)
X-Original-To: sc22wg5@open-std.org
Delivered-To: sc22wg5@open-std.org
Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25])
	by www2.open-std.org (Postfix) with ESMTP id 4FC60C178E4
	for <sc22wg5@open-std.org>; Wed, 30 Mar 2011 19:40:42 +0200 (CET DST)
Received: from source ([136.162.34.10]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP
	ID DSNKTZNrGdbkFUSLTkycJ3Ksjv/1EraLNARE@postini.com; Wed, 30 Mar 2011 10:40:46 PDT
Received: from fortran.us.cray.com (172.31.19.200) by
 cfexcas01.americas.cray.com (172.30.74.226) with Microsoft SMTP Server (TLS)
 id 8.3.137.0; Wed, 30 Mar 2011 12:40:40 -0500
Message-ID: <4D936B2C.7090703@cray.com>
Date: Wed, 30 Mar 2011 12:41:00 -0500
From: Bill Long <longb@cray.com>
Reply-To: <longb@cray.com>
Organization: Cray Inc.
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: fortran standards email list for J3 <j3@j3-fortran.org>
Cc: Jim Xia <jimxia@ca.ibm.com>,
	"sc22wg5@open-std.org" <sc22wg5@open-std.org>,
	"j3-bounces@j3-fortran.org" <j3-bounces@j3-fortran.org>
Subject: Re: (j3.2006) (SC22WG5.4424)    WG informal ballot
References: <20110303174947.DD0CAC3BA01@www2.open-std.org> <20110325193010.B3704C178DA@www2.open-std.org> <20110326180217.D7297C178DA@www2.open-std.org> <20110330161027.BDE13C178E4@www2.open-std.org>
In-Reply-To: <20110330161027.BDE13C178E4@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 3/30/11 11:10 AM, Jim Xia wrote:
>
> Addition comments from IBM (C side people)
>
>
> 3.3.{3,4} Seems to indicate runtime or generated code should do
> deallocation. Note that in C if no stdlib is included and no C lib is
> linked, this force programs to link in a library that they didn't want.
>

The text in 3.3 p3 and p4 applies only to the case where either the 
caller or callee is in Fortran. In that case, the deallocation is always 
done by Fortran, not by C.  So the concern raised above does not exist. 
  In a C to C call, the concept of INTENT(OUT) does not exist.


> 5.2.2: base_addr: Says if the object has zero size the value is not
> NULL. However the C standard allows NULL return values from malloc(0).
>

Hence, don't use the output from malloc() if the size is zero.  Or, more 
obviously, don't even call malloc() to get the base_addr if the size is 
zero.

> 5.2.2, 5.2.3: Was there a reason to allow any order for the middle
> elements? This seems to decrease portability between compilers.
>

It can help with alignment, and possibly better match with the vendor's 
Fortran descriptor.  Furthermore, the vendor is permitted to (very 
likely will) include additional hidden members in the C descriptor. 
Portability between C compilers has never been a goal of interop.


> 5.2.4 p3 seems to conflict with 5.2.5.5 p7, should the 15 there not be
> the macro value?
>

Some vendors (IBM among them, if I recall) already support ranks > 15. 
The macro value is the actual max rank supported.  The minimum value of 
15 is from the Fortran minimum requirement.


> 5.2.5.5 p3 indicates that it can establish a C descriptor for an object
> or a subobject of it implying that even if the user wanted a descriptor
> for an object they could end up getting a descriptor for a subobject.
>

It is up to the user to set the base_addr correctly if a subobject is 
desired.  The user decides what is wanted here.


> 6.3 p3 Grammar error: "that are *of* assumed type".
>

Noted.

>
> I think the first comment is serious enough to reconsider the
> requirement on INTENT(OUT) for allocatables.
>

Reconsideration of the requirement on INTENT(OUT) for allocatables is an 
issue for change to the base Fortran standard, and not related to the 
TR.  The TR just maintains consistency with the current Fortran rules.

Cheers,
Bill


>
> Thanks,
>
> Jim Xia
>
> Compiler Testing, X10 & XLF
> IBM Toronto Lab at 8200 Warden Ave,
> Markham, On, L6G 1C7
> 905-413-3444

-- 
Bill Long                                           longb@cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101


