(j3.2006) (SC22WG5.4424) WG informal ballot

[Bill Long]

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 at 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