(j3.2006) (SC22WG5.5049) [ukfortran] ts29113 compiler conformance table

Malcolm Cohen malcolm
Wed Jul 31 02:12:10 EDT 2013


I would recommend greatly simplifying this spreadsheet.  With all due respects, Reinhold?s 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?s point of view or a user?s 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?t 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.

?Assumed-shape array arguments, array element addressing and contiguity?
-> ?Assumed-shape arguments for BIND(C)?.

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 ?passing the correct values in the descriptor?.  There is no value in mentioning them separately.

?Creating descriptors and Fortran objects in C?
This is somewhat misleading, as Reinhold?s 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...
->?CFI_CDESC_T and CFI_establish?

(Actually CFI_CDESC_T is necessarily part of a conformant ISO_Fortran_binding.h... and I don?t see why anyone would bother to provide ISO_Fortran_binding.h without having implemented CFI_establish!)

?Dynamic memory management and pointer assignment?
-> ?CFI_allocate, CFI_setpointer, CFI_deallocate?

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.

?Array sections and type components?
-> ?CFI_section and CFI_select_part?

REASON: Just list the functions...

Actually, one could reasonably argue that these two don?t have to be implemented at the same time, but since they are both easy I don?t think it matters.

?Assumed-rank entities?
->?Assumed rank?

REASON: That is what the feature is called.  Saying ?Assumed-rank things? is not an improvement over simple ?Assumed rank? (?entity? is just a posh word for ?thing?).

?Assumed-type entities?
->?Assumed type? or ?TYPE(*)?

REASON: Either give the name of the feature, or the syntax that determines it.

I agree with Bill that you should add
  ?Pass scalar to assumed-size assumed-type?
or
   ?Pass scalar to TYPE(*) DIMENSION(*)?

?Non-interoperable objects and functions?
might be better split into
  ?Non-interoperable array for C_LOC/C_F_POINTER?
and
  ?Non-interoperable function for C_FUNLOC/C_F_PROCPTR?
Even if you don?t split it, at least change ?objects? to ?arrays? (we have had non-interoperable scalar passing for some time).

?Extension of asynchronous processing?
->?New semantics for ASYNCHRONOUS attribute?

ADD:
  ?RANK intrinsic function?
  ?Allocatable arguments for BIND(C)?
  ?Pointer arguments for BIND(C)?

REASON: If these are meant to be implied somewhere else, I didn?t see it.


From: Ian Chivers 
Date: ?? 25?7?29? 18:00
To: 'sc22wg5' 
Subject: [ukfortran] (SC22WG5.5043) ts29113 compiler conformance table

Here is a spreadsheet I have created concerning

TS29113.

 

Copies of the spreadsheet and Reinhold's

draft paper can be found at

 

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

 

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.

 

please correct the spreadsheet if there are any errors.

 

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

later today.



--------------------------------------------------------------------------------
_______________________________________________
ukfortran mailing list
http://lists.accu.org/mailman/listinfo/ukfortran
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20130731/3b5ba22d/attachment-0001.html 



More information about the J3 mailing list