• GFortran45_actions

#gfortran Meeting of 28th November 2008 to discuss developments for gfortran-4.5.

• See also GFortran45 - or rather: GFortran46

Summary notes by Tobias Burnus, with some additions and embellishments by Paul Thomas, and Jerry D.

Highlights and Actions:

- (Action)Paul will review Daniel K.'s FINALization patch and send the CLASS patch to Daniel K. - CLASS, DEFERRED, type-bound OPERATORS:

• (Action)Daniel K. will work on this.

- (Action)Paul will work on the array descriptor

• flag changes such as dim will be done

• ubound -> extends change: Maybe, need to check whether it is

  • really profitable and not just a lot of work giving worse performace Need to check with Richard (for his middle-end array work)

    See: ftp://ftp.nag.co.uk/sc22wg5/N1751-N1800/N1761.txt for the TR which defines the C interoperable array descriptor and http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/fbfe6c6fd3950160/ for claims that extend is faster than ubound (Thomas suggests to start use macros in the library, to make changing the descriptor easier). (Action)Paul & Tobias will try to solve the ubound/extends (vs. middl end) issue

- library: We probably break the ABI compatibility; the array

• descriptor touches too many places

- multiple decls per function:

• - Initial patch: http://gcc.gnu.org/ml/fortran/2008-02/msg00005.html

  • Revised plan: http://gcc.gnu.org/ml/fortran/2008-05/msg00247.html

  - Unclear whether needed for the LTO (link-time optimization) branch,
  • but otherwise should lead to better code (inlining) and to whole-file checking.

  - (Action)Paul wants to look at his old patch, cf.

  • http://gcc.gnu.org/ml/fortran/2008-05/msg00253.html (Then we probably can also re-anable the -combine option.)

  - (Action)Paul to contact Steven

- Missed optimization: Inlining matmul, unneeded temps etc.

• (Action)Dominique, Thomas and Mikael want to investigate. (PR 32512 shows how much can be gained e.g. for SPREAD)

- Run time checking

• - bounds checking: (Action)Esp. Thomas wants to work on it - Call checking: recursive and argument checking,

  • (Action)Daniel K. and Tobias want work on this

- I/O optimization:

• Improving gfortran I/O performance will require several steps. The following are proposed not in a particular order.
• - Consider adding a -fno-iochecks flag that will simply skip most of the checks done in data_transfer_init (Jerry)
• - On list directed formatted read, convert next_char to use fbuf and simple pointer operations. (Janne)
• - Split data_transfer_init into read_data_transfer_init and write_data_transfer_init. (Jerry)
• - Factor out formatted/unformatted, stream/non-stream, direct/sequential. (Thomas and Jerry)
  • The concept here is to eliminate any conditional checks at runtime by either setting the function calls directly at compile time or setting the transfer function pointer to an appropriate specific function at time of initialization (data_transfer_init).
• - Consider eliminating the large case statement for format token interpretation with a tight loop of linked function calls built at compile time to avoid this step at run-time unless the string is a variable.
• - Review the handling of implicit do loops to include certain checks inside the loop to detect early exit. (PR32382 and PR35339)

- Scalar allocation and errmsg=: (Action)Steve want to work on this,

• with help of Paul for trans*

- parameterized derived types:

• (Action)Paul will contact Sa Liu and look at her patch http://users.physik.fu-berlin.de/~tburnus/tmp/dt.txt http://users.physik.fu-berlin.de/~tburnus/tmp/derived-param.txt

- procedure pointer components

• - (Action)Tobias will contact Janus (Hi!) and look at sorting out the

  • remaining issues

  - (Action)Andrew will help with TREE-related parts (PR 38152 needs also some TREE fixes.) - Not talked about TODO item: proc-pointer-returing functions

- F2003 pointer assignment / rank remampping,

• See PR 29785. Deferred to 4.6 ?

- F2003 I/O, left to do:

• - The initial patch developed for widechar internal units was fairly intrusive and used a modified version of memcpy to implement. It may be better to actually implement a widechar memory unit in unix.c to handle this more transparently.
• - Rounding modes is ready in the front-end. What remains is to implement the runtime. Currently rounding is handled in a fixed point numeric string format within output_float. Additional logic will need to be added there to do rounding in different modes. I suggest we create a helper function for each mode. These go into write_float.def.
• - Full Asynchronous I/O would be a nice addition. Not all platforms can support this feature. The first step here is to survey platforms and determine those for which it is supported. We will need some configury magic so that we conditionally compile the code to handle this. Jerry will elaborate further here how to do this in gfortran.
• - User Defined Derived Type I/O will take some work. We will need to modify the derived type structures to include a pointer to a user defined function for each type and possibly some sort of nested list to traverse through all sub-types, executing the I/O calls. Jerry suggests we create a design diagram of some sort to depict the desired run-time behaviour and pseudo data structures needed. Then we can decide the division of work between front-end and run-time. Ideally the front-end would compile a linked list of function calls and the run-time would simply implement an "execution loop" to traverse the list.

- IEEE

• - (Action)Steve wants to contact Asher, who intended to create a patch

• - (Action)Tobias also wants to look into this (question to GCC)

- C interoperability TR (link, see above):

• - (Action)Tobias might do TYPE(*), dimension(..) and "optional" for

  • 4.5, depending on time constrains

- submodules - Steve L: one of most requested features

• Paul has notes about it in his copy of MR&C ... (Action)Get them out!

- Coarrays:

• - Chinese friends have a full-featured implementation ... - Toon: at the GCC Summit someone (who?) said: Let libgomp be
  • the library to talk to from a coarray GNU Fortran - and we deal with the rest (whether shared or distributed memory).

  - GCC UPC uses the http://gasnet.cs.berkeley.edu/,

  • no immediate plan to merge GCC UPC with GCC, but friendly email contact
  - Single image and thread-mode without needing to do any
  • configuration is desirable. coarray+OpenMP programs should work.

- CPP w/o traditional mode: Daniel F. and Tobias might do something on

• this (not very high priority)

- STDCALL: Deemed as useful, but no one volunteering - ASSOCIATED: Useful, deferred to later meetings when the TODO list

• is smaller

- Fortran 2008's CONTIGUOUS: Ditto. - (Action)We will create a wiki page to collect all Stage1 patches (esp.

• the accepted ones)

Things that pault noted were not discussed (he forgot:-))

- (Action)Fixing the allocatable component leaks - Paul;

- Allocate on assignment for allocatable arrays as well as allocatable components

- Improve module reading - whilst faster than it used to be, it could still be improved.