From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Wed Jul 31 08:28:31 2013 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 63CA09DB146; Wed, 31 Jul 2013 08:28:30 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from nag-j.co.jp (nag-j.co.jp [111.68.142.10]) by www.open-std.org (Postfix) with ESMTP id A08FB3570CB for ; Wed, 31 Jul 2013 08:28:28 +0200 (CEST) Received: from Maru6 (218-42-159-105.cust.bit-drive.ne.jp [218.42.159.105]) (authenticated bits=0) by nag-j.co.jp (8.14.5/8.14.5) with ESMTP id r6V6CB6x099430 for ; Wed, 31 Jul 2013 06:12:13 GMT (envelope-from malcolm@nag-j.co.jp) Message-ID: <241320DCBA7B4B6590627C63A2CFDFFE@Maru6> From: "Malcolm Cohen" To: "'sc22wg5'" References: <20130724235846.299F4357176@www.open-std.org> <51F0DD9B.6040802@net-b.de><20130725222446.98834357194@www.open-std.org> <20130729085936.D199A35717D@www.open-std.org> In-Reply-To: <20130729085936.D199A35717D@www.open-std.org> Subject: Re: [ukfortran] (SC22WG5.5043) ts29113 compiler conformance table Date: Wed, 31 Jul 2013 15:12:10 +0900 Organization: =?UTF-8?B?5pel5pysTkFH?= MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AD_01CE8E00.543B26F0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00AD_01CE8E00.543B26F0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would recommend greatly simplifying this spreadsheet. With all due = respects, Reinhold=E2=80=99s paper is a good overview of using the TS = but is not remotely close to a list of features (which is what is = preferred for something like this), and section titles are a poor = substitute for feature names. All of the 1.x items should be deleted, and a new item 1 which simply = reads: TS-conformant ISO_Fortran_binding.h REASON: No-one is going to supply a CFI_cdesc_t that has elem_len and is = missing base_addr, in fact no-one is going to supply a CFI_cdesc_t that = does not include all of the mandated fields. In the event someone = supplies such a file and it does not provide all the values required, = just marking this as N (or P at a pinch) is perfectly good enough. I briefly considered whether it made sense to separate out an = ISO_Fortran_binding.h that was missing some required function = declarations, macros, types, or values, and frankly I do not see any = case for bothering with that (either from an implementor=E2=80=99s point = of view or a user=E2=80=99s point of view). Either one has a usable = ISO_Fortran_binding.h, or one does not. So although in principle you = could have separate lines for ISO_Fortran_bind.h supplied Conformant CFI_desc_t Conformant CFI_dim_t CFI_attribute_* macross CFI_type_* macros CFI blah blah blah etc. I don=E2=80=99t really see separating those as adding any value. = Indeed, by giving compilers points for having a defective = ISO_Fortran_binding.h, I would argument the value would be negative! In = any case, it is almost trivial to construct a conformant = ISO_Fortran_binding.h once one has the CFI_desc_t type. =E2=80=9CAssumed-shape array arguments, array element addressing and = contiguity=E2=80=9D -> =E2=80=9CAssumed-shape arguments for BIND(C)=E2=80=9D. REASON: Once the compiler supports passing an assumed-shape array to a = BIND(C) procedure, and has a conformant CFI_cdesc_t (part and parcel of = ISO_Fortran_binding.h), the array element addressing and contiguity = considerations simply fall out of =E2=80=9Cpassing the correct values in = the descriptor=E2=80=9D. There is no value in mentioning them = separately. =E2=80=9CCreating descriptors and Fortran objects in C=E2=80=9D This is somewhat misleading, as Reinhold=E2=80=99s paper does not (in = this section) list all the CFI_desc_t related macros and functions that = are involved in such an operation. In fact all that section uses is the = macro CFI_CDESC_T and the function CFI_establish. Therefore... ->=E2=80=9DCFI_CDESC_T and CFI_establish=E2=80=9D (Actually CFI_CDESC_T is necessarily part of a conformant = ISO_Fortran_binding.h... and I don=E2=80=99t see why anyone would bother = to provide ISO_Fortran_binding.h without having implemented = CFI_establish!) =E2=80=9CDynamic memory management and pointer assignment=E2=80=9D -> =E2=80=9CCFI_allocate, CFI_setpointer, CFI_deallocate=E2=80=9D REASON: Just list the functions. Everyone is going to have the TS = immediately to hand, fewer are going to want to wade through text = discussing how to do stuff just to find out what the functions are. =E2=80=9CArray sections and type components=E2=80=9D -> =E2=80=9CCFI_section and CFI_select_part=E2=80=9D REASON: Just list the functions... Actually, one could reasonably argue that these two don=E2=80=99t have = to be implemented at the same time, but since they are both easy I = don=E2=80=99t think it matters. =E2=80=9CAssumed-rank entities=E2=80=9D ->=E2=80=9DAssumed rank=E2=80=9D REASON: That is what the feature is called. Saying = =E2=80=9CAssumed-rank things=E2=80=9D is not an improvement over simple = =E2=80=9CAssumed rank=E2=80=9D (=E2=80=9Centity=E2=80=9D is just a posh = word for =E2=80=9Cthing=E2=80=9D). =E2=80=9CAssumed-type entities=E2=80=9D ->=E2=80=9DAssumed type=E2=80=9D or =E2=80=9CTYPE(*)=E2=80=9D REASON: Either give the name of the feature, or the syntax that = determines it. I agree with Bill that you should add =E2=80=9CPass scalar to assumed-size assumed-type=E2=80=9D or =E2=80=9CPass scalar to TYPE(*) DIMENSION(*)=E2=80=9D =E2=80=9CNon-interoperable objects and functions=E2=80=9D might be better split into =E2=80=9CNon-interoperable array for C_LOC/C_F_POINTER=E2=80=9D and =E2=80=9CNon-interoperable function for C_FUNLOC/C_F_PROCPTR=E2=80=9D Even if you don=E2=80=99t split it, at least change = =E2=80=9Cobjects=E2=80=9D to =E2=80=9Carrays=E2=80=9D (we have had = non-interoperable scalar passing for some time). =E2=80=9CExtension of asynchronous processing=E2=80=9D ->=E2=80=9DNew semantics for ASYNCHRONOUS attribute=E2=80=9D ADD: =E2=80=9CRANK intrinsic function=E2=80=9D =E2=80=9CAllocatable arguments for BIND(C)=E2=80=9D =E2=80=9CPointer arguments for BIND(C)=E2=80=9D REASON: If these are meant to be implied somewhere else, I = didn=E2=80=99t see it. From: Ian Chivers=20 Date: =E5=B9=B3=E6=88=90 25=E5=B9=B47=E6=9C=8829=E6=97=A5 18:00 To: 'sc22wg5'=20 Subject: [ukfortran] (SC22WG5.5043) ts29113 compiler conformance table Here is a spreadsheet I have created concerning TS29113. =20 Copies of the spreadsheet and Reinhold's draft paper can be found at =20 http://rhymneyconsulting.co.uk/fortran/fortran_forum/ =20 I would be grateful if the compiler vendors on the list could fill in the table and return it and i'll include their replies in the december edition of fortran forum. =20 please correct the spreadsheet if there are any errors. =20 I will be circulating to the other vendors when i get time later today. -------------------------------------------------------------------------= ------- _______________________________________________ ukfortran mailing list http://lists.accu.org/mailman/listinfo/ukfortran --=20 ................................Malcolm Cohen, Nihon NAG, Tokyo. ------=_NextPart_000_00AD_01CE8E00.543B26F0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would recommend greatly simplifying this=20 spreadsheet.  With all due respects, Reinhold=E2=80=99s paper is a = good overview of=20 using the TS but is not remotely close to a list of features (which is = what is=20 preferred for something like this), and section titles are a poor = substitute for=20 feature names.
 
All of the 1.x items should be deleted, and a = new item 1=20 which simply reads:
  TS-conformant = ISO_Fortran_binding.h
 
REASON: No-one is going to supply a CFI_cdesc_t = that has=20 elem_len and is missing base_addr, in fact no-one is going to supply a=20 CFI_cdesc_t that does not include all of the mandated fields.  In = the event=20 someone supplies such a file and it does not provide all the values = required,=20 just marking this as N (or P at a pinch) is perfectly good = enough.
 
I briefly considered whether it made sense to = separate out=20 an ISO_Fortran_binding.h that was missing some required function = declarations,=20 macros, types, or values, and frankly I do not see any case for = bothering with=20 that (either from an implementor=E2=80=99s point of view or a = user=E2=80=99s point of=20 view).  Either one has a usable ISO_Fortran_binding.h, or one does=20 not.  So although in principle you could have separate lines=20 for
   ISO_Fortran_bind.h = supplied
   Conformant CFI_desc_t
   Conformant CFI_dim_t
   CFI_attribute_* = macross
   CFI_type_* macros
   CFI blah blah blah = etc.
I don=E2=80=99t really see separating those as = adding any=20 value.  Indeed, by giving compilers points for having a defective=20 ISO_Fortran_binding.h, I would argument the value would be = negative!  In=20 any case, it is almost trivial to construct a conformant = ISO_Fortran_binding.h=20 once one has the CFI_desc_t type.
 
=E2=80=9CAssumed-shape array arguments, array = element addressing=20 and contiguity=E2=80=9D
-> =E2=80=9CAssumed-shape arguments for = BIND(C)=E2=80=9D.
 
REASON: Once the compiler supports passing an=20 assumed-shape array to a BIND(C) procedure, and has a conformant = CFI_cdesc_t=20 (part and parcel of ISO_Fortran_binding.h), the array element addressing = and=20 contiguity considerations simply fall out of =E2=80=9Cpassing the = correct values in the=20 descriptor=E2=80=9D.  There is no value in mentioning them = separately.
 
=E2=80=9CCreating descriptors and Fortran = objects in=20 C=E2=80=9D
This is somewhat misleading, as = Reinhold=E2=80=99s paper does not=20 (in this section) list all the CFI_desc_t related macros and functions = that are=20 involved in such an operation.  In fact all that section uses is = the macro=20 CFI_CDESC_T and the function CFI_establish.  = Therefore...
->=E2=80=9DCFI_CDESC_T and = CFI_establish=E2=80=9D
 
(Actually CFI_CDESC_T is necessarily part of a = conformant=20 ISO_Fortran_binding.h... and I don=E2=80=99t see why anyone would bother = to provide=20 ISO_Fortran_binding.h without having implemented = CFI_establish!)
 
=E2=80=9CDynamic memory management and pointer=20 assignment=E2=80=9D
-> =E2=80=9CCFI_allocate, CFI_setpointer,=20 CFI_deallocate=E2=80=9D
 
REASON: Just list the functions.  Everyone = is going=20 to have the TS immediately to hand, fewer are going to want to wade = through text=20 discussing how to do stuff just to find out what the functions = are.
 
=E2=80=9CArray sections and type = components=E2=80=9D
-> =E2=80=9CCFI_section and = CFI_select_part=E2=80=9D
 
REASON: Just list the functions...
 
Actually, one could reasonably argue that these = two don=E2=80=99t=20 have to be implemented at the same time, but since they are both easy I = don=E2=80=99t=20 think it matters.
 
=E2=80=9CAssumed-rank = entities=E2=80=9D
->=E2=80=9DAssumed rank=E2=80=9D
 
REASON: That is what the feature is = called.  Saying=20 =E2=80=9CAssumed-rank things=E2=80=9D is not an improvement over simple = =E2=80=9CAssumed rank=E2=80=9D (=E2=80=9Centity=E2=80=9D=20 is just a posh word for =E2=80=9Cthing=E2=80=9D).
 
=E2=80=9CAssumed-type = entities=E2=80=9D
->=E2=80=9DAssumed type=E2=80=9D or = =E2=80=9CTYPE(*)=E2=80=9D
 
REASON: Either give the name of the feature, or = the syntax=20 that determines it.
 
I agree with Bill that you should = add
  =E2=80=9CPass scalar to assumed-size=20 assumed-type=E2=80=9D
or
   =E2=80=9CPass scalar to TYPE(*)=20 DIMENSION(*)=E2=80=9D
 
=E2=80=9CNon-interoperable objects and = functions=E2=80=9D
might be better split into
  =E2=80=9CNon-interoperable array for=20 C_LOC/C_F_POINTER=E2=80=9D
and
  =E2=80=9CNon-interoperable function for=20 C_FUNLOC/C_F_PROCPTR=E2=80=9D
Even if you don=E2=80=99t split it, at least = change =E2=80=9Cobjects=E2=80=9D to=20 =E2=80=9Carrays=E2=80=9D (we have had non-interoperable scalar passing = for some=20 time).
 
=E2=80=9CExtension of asynchronous = processing=E2=80=9D
->=E2=80=9DNew semantics for ASYNCHRONOUS=20 attribute=E2=80=9D
 
ADD:
  =E2=80=9CRANK intrinsic = function=E2=80=9D
  =E2=80=9CAllocatable arguments for = BIND(C)=E2=80=9D
  =E2=80=9CPointer arguments for = BIND(C)=E2=80=9D
 
REASON: If these are meant to be implied = somewhere else, I=20 didn=E2=80=99t see it.
 
 
From: Ian Chivers
Date: =E5=B9=B3=E6=88=90 25=E5=B9=B47=E6=9C=8829=E6=97=A5 = 18:00
Subject: [ukfortran] (SC22WG5.5043) ts29113 compiler = conformance=20 table
 

Here=20 is a spreadsheet I have created concerning

TS29113.

 

Copies=20 of the spreadsheet and Reinhold's

draft=20 paper can be found at

 

http://rhymneyconsulting.co.uk/fortran/fortran_forum/=

 

I=20 would be grateful if the compiler vendors on the = list

could=20 fill in the table and return it

and=20 i'll include their replies in the december edition

of=20 fortran forum.

 

please=20 correct the spreadsheet if there are any errors.

 

I=20 will be circulating to the other vendors when i get = time

later=20 today.

_______________________________________________
ukfortran mailing=20 list
http://lists.accu.org/mailman/listinfo/ukfortran
--=20
................................Malcolm Cohen, Nihon NAG,=20 Tokyo.
------=_NextPart_000_00AD_01CE8E00.543B26F0--