The Real Doctors of Fortran

In this blog, I refer to myself as "Doctor Fortran".  It's a joke that started more than ten years ago when I decided to write an "advice column" for what was then the Digital Visual Fortran Newsletter.  Everyone liked it so much I stuck with it, but I've always been aware of the people who deserve that title far more than I - the members of the Fortran standards committee.  As it happens, I am an "alternate" member of the committee representing Intel, but most of the time we are represented by Stan Whitlock.  Intel Fortran developer Lorri Menard is our other alternate member.  I've now attended three standards meetings and thought I'd write up my experience of the most recent and give readers a feel for how the Fortran language's evolution is guided and its cohesiveness maintained.

First, some background.  There is the International Standards Organization (ISO) Fortran committee whose full designation is ISO/IEC/JTC1/SC22/WG5.  We'll call that WG5 for short. WG5 has members from around the world - its charter is to establish the direction for the Fortran standard: at a high level, which features should it have?  WG5 also has the final approval on a new standard, with each member country having one vote. WG5 meets once a year at a location that shifts among various member host countries.

WG5 doesn't do the nuts-and-bolts work of developing the standard - that task is assigned to the US Fortran standards committee, a subset of WG5.  Formally called INCITS PL22.3, members typically refer to it as J3, a term dating back to the American National Standards Institute (ANSI) X3J3 committee. J3 has representatives from vendors (Cray, IBM, Intel, NAG, Oracle) and users (universities, national labs and individuals.)  The J3 meetings, held three times a year, are also regularly attended by voting alternates from inside and outside the US, including Toon Moene of the gfortran project. One of the three yearly J3 meetings is held coincident with the yearly WG5 meeting.

It was my honor to be Intel's representative at the June 2011 joint WG5/J3 meeting, held in Garching, Germany, a pleasant suburb of Munich, at the LRZ Supercomputing Center (LRZ stands for Leibniz-Rechenzentrum or Leibniz Research Center.)  The Fortran 2008 standard had been approved the previous October, so you might think we didn't have much to do, but the week was full. No, we were not starting to design the features for the next Fortran standard - in fact, it was generally agreed that wouldn't happen for another year or two, and WG5 still needed to come up with the general direction for the next standard.  Many members of J3 and WG5, including myself, are of the opinion that the next standard should be a "corrections and clarifications" version with few or no new features so that vendors and users have a chance to "catch up".

The biggest work item was TS 29113 on Enhanced C Interoperability. In standards speak, TS means Technical Specification and in this case is used when there is a language feature whose design is not complete in time for standards approval but is firm enough to encourage vendors to implement it.  (In the past, this was called TR for Technical Report.)  Typically, when a TS has been approved it is agreed that it will be incorporated in the next standard as-is, minimizing risk to vendors and users. The most well-known use of a TS in the past was the one that brought us allocatable components of derived types, incorporated into Fortran 2003.

TS 29113, or "the Interop TS", wants to extend the C interoperability features of Fortran in two main ways:

    • Allow C procedures to be passed assumed-shape, pointer and allocatable variables and to give C programmers the means to read, write, and reallocate such arguments, and also to allow C to define such variables and pass them to Fortran

    • Provide support for interoperability with a C "void *" argument that has no explicit type or shape

The TS underwent significant changes during the week, but the fundamental ideas remained:

    • The concept of "assumed type", designated by TYPE(*), and "assumed rank", designated by DIMENSION(..).  Think of the .. as a colon on its side - DIMENSION(*) already has a meaning in Fortran

    • The notion of a "C descriptor" with a known structure, and a C header file that declares the structure and functions C code can call to manipulate these descriptors.

For more details on the Interop TS, you can read the current TS 29113 draft (PDF).

The other major task that occupied us was interpretations.  These are submitted by users and vendors when they think there is an ambiguity in the standard or they want to know if a particular meaning was intended by the committee.  There was quite a backlog of these, as development of F2008 had taken up a lot of time, but we knocked off a lot of them. I remember one I worked on which asked if parameterized derived types could have the SEQUENCE attribute, as if they could, this greatly complicated the process of determining when two derived type declarations were "the same".  (We concluded that it made no sense to allow parameterized derived types to be SEQUENCE types.)  Another interpretation lifted the restriction that the arguments to C_LOC and C_F_POINTER be interoperable, greatly increasing their usability.

The process works this way.  One or more members takes an interpretation request and, if necessary, rewrites it to refer to the current standard, since many were submitted against Fortran 2003.  An answer is proposed - it may be that the standard is correct as-is and no change is required, or a wording change is proposed.  The answer is then voted on by the members present.  Sometimes there are objections and another revision is made.  If the interpretation is approved, it then goes on a letter ballot submitted to all J3 members, who can approve, approve with comments, or reject (with comments).  Lastly, a ballot of WG5 members is done. Only if the interpretation passes this third round is it considered part of the standard, and later included in a set of edits called a corrigendum.

As a break from working on the standard, we got a tour of LRZ's immense building housing its multiple supercomputer clusters.  Photographs were not allowed in here, but I was impressed by the extensive and elaborate lightning and fire suppression systems.  Later in the week we also got a tour of the Munich Computer Museum, with working examples of many significant computers from the past.  You can view a gallery of the photos I took here.  And then there was the atrium of the LRZ building where we ate lunch.  It features two giant tube slides that go from the fourth floor down to the first.  Blankets were provided if you wanted to try it out, but I didn't see anyone do so while I was there.

Slides at LRZ

Each time I have attended a standards meeting, I have been impressed with the members' dedication to the Fortran language.  While there are a variety of personalities on the committee, they all work together to make Fortran the best it can be.  I'm glad to have been a small part of this effort and look forward to future opportunities to participate in Fortran's future.

For more complete information about compiler optimizations, see our Optimization Notice.


Steve Lionel (Intel)'s picture

Sorry, that link should be

Steve Lionel (Intel)'s picture

Gary, please ask "how to" questions in our user forum software. Blog post comments are just for comments on the post.


anonymous's picture

Maybe you guys can help me?

As you will see I need a lot of help.

I am 'returning' to Fortran after around 25 years of abstinence - forced return due to taking on a project at work as a result of the designers leaving the organisation. I have 'volunteered' to have a look at the code - its a ship navigation code, ODE solver set of routines - as I am old enough to at least have come across Fortran programmes!

I have started trawling through the thing but have come across something that I haven't seen before - its a % sign - as in

LocVel(ibody) % u_ship = XX(v_index+1)

Can anyone enlighten me - could do with a good Fortran book I think - on what this % sign does/is?

All comments welcome - appreciate its probably a bit low-brow - but just starting out on the learning curve again!


jimdempseyatthecove's picture

In the circumstance of Fortran calling C, I can see the utility of a declaration of an argument with assumed rank as an indicator to pass the array descriptor reference as opposed to passing the first location of the blob of data. (else simply pass the first cell by reference and size as additional arg).

In a situation were Fortran is calling C with an assumed rank with a minimum requirement of rank 2, I suggest

subroutine Cfunc(a)
real(:,:,..) ! colon, colon, dotot
end subroutine Cfunc
end interface

In this case the Fortran compiler can assert at compile time the minimun rank requirements for the subroutine call.
You might ask others on the committee as to if this would make sense.
You won't be able to a compile time assert of C calling Fortran, but you can for Fortran to Fortran as well as Fortran to C.
These efforts of the committee are to stronger type check while simplifying the coding requirements. I think this suggestion does both without interfering with the current (..) syntax.


Steve Lionel (Intel)'s picture

Hi, Jim. No - assumed rank means any rank - you cannot specify some of the bounds and then "optional additional dimensions". The expectation is that the typical usage of assumed rank is for calling C from Fortran, but we insisted on making it possible for a Fortran routine to be called with such a thing. The new RANK intrinsic allows you to determine the rank. I'd expect most Fortran routines accepting an argument of assumed rank or type to either treat it as a blob of bytes or to "cast" it to a regular Fortran type/rank using C_LOC and C_F_POINTER. There was even an example of this in the TS at one point but it was removed at the objection of some members. (I disagreed.)

jimdempseyatthecove's picture

Steve, thanks for your pictures of the computer museum - brings back some memories.

RE: standards

Committee within a committee within dispersed organization - it is a wonder you get anything done. Keep up the good work.

RE: assumed rank

I read the link to the TS 29113 draft and have a question for clarification regarding assumed rank.
In a subroutine you can declare a list of required arguments followed by a list of optional arguments.
Does the implementation have an analog to this:

subroutine foo(n,m,x)
integer : n,m
real :: x(n,m,..)

Meaning requires x with a rank of at least 2 (or 3).

anonymous's picture

Awsome architcture!

Add a Comment

Have a technical question? Visit our forums. Have site or software product issues? Contact support.