In Fortran-speak, an "interface" is information about a callable procedure. Fortran 77 had only "implicit interface" where the only thing you could say about a procedure was the datatype of a function result. While the language said that arguments in a call must match in number, order, type and rank (number of dimensions), there was no way to describe the arguments so that the compiler could check them. Furthermore, a compiler did not need to know these things because it didn't affect how arguments were passed.

Enter Fortran 90. Suddenly, things get a lot more complicated. For example, a dummy argument could be an assumed-shape array, requiring the call to supply information about the array bounds. Arguments could be OPTIONAL, requiring the caller to somehow indicate that an argument was omitted. Even more fun, a function could return an array or a character value whose length was dependent on some function of the arguments. All of these things, and more, required the ability to describe in detail the procedure and its arguments so that the compiler could call the procedure the right way. This information also helped correctness as the compiler could now check to make sure you were passing the correct arguments. This set of information is called an "explicit interface".

There are several ways to provide an explicit interface. The simplest and best way is to put the procedure in a module, or make it a CONTAINed procedure of the calling program or procedure. This has the advantage of not requiring you to write the information twice and thus increasing the chances of getting it wrong in one of the places. When you have a module procedure, or a contained procedure, its interface is automatically visible to everything else in the module or in the parent scope. Assuming the name hasn't been declared PRIVATE, the interface is also available to places where you USE a module containing a module procedure.

There is an additional way of declaring an explicit interface, an INTERFACE block. In most cases, you should avoid writing INTERFACE blocks for Fortran procedures as it duplicates information, but sometimes it can be handy to do so if you are updating an older program. Just remember that the language does not allow "interface to self" - that means, you can't have an interface visible in the scope where the procedure itself is defined. Note that my admonition to avoid INTERFACE blocks doesn't apply when you want to declare a generic interface as long as you use a MODULE PROCEDURE or PROCEDURE declaration in the list of specific routines in the generic interface.

In many cases, especially if you are sticking to abilities that were in Fortran 77, you don't have to provide explicit interfaces, though it's a good idea to do so. But, as I explained in my 2001 article, there are circumstances where the language requires you to have an explicit interface visible to the caller. The list of things that trigger this requirement grew in Fortran 2003 and again in Fortran 2008. Here is the current list (section 12.4.2.2 of Fortran 2008 if you want to follow along):

A procedure other than a statement function shall have an explicit interface if it is referenced and

1. a reference to the procedure appears
   1. with an argument keyword, or,
   2. in a context that requires it to be pure,
2. the procedure has a dummy argument that
   1. has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, VALUE, or VOLATILE attributes,
   2. is an assumed-shape array,
   3. is a coarray,
   4. is of a parameterized derived type, or
   5. is polymorphic,
3. the procedure has a result that
   1. is an array,
   2. is a pointer or is allocatable, or
   3. has a nonassumed type parameter value that is not a constant expression,
4. the procedure is elemental, or
5. the procedure has the BIND attribute.

(The small text designates features that are deemed obsolescent or "deprecated" )

The most common mistake made in not providing an explicit interface is when calling procedures with OPTIONAL or POINTER arguments. Programmers read about these features and decide to add them to their F77-style code, and then complain when the program dies with errors such as access violation. But how can you find the places where you need an explicit interface? Intel Fortran is here to help!

Since version 9.1, the Intel compiler has supported a feature called Generated Interface Checking. If this is enabled and the compiler sees an "external" procedure (one not in a module or otherwise CONTAINed), it generates an interface based on the attributes it sees and saves it in a compiled module file (.mod) with the name of the procedure followed by "__genmod.mod". It also generates a .f90 file with a human-readable version of this interface, but this is not used by the compiler. Then, when it comes across a call to a procedure for which there is not already an explicit interface, it looks to see if there is a generated one. NOT as a substitute for where the language requires it, but so that it can compare the call to the generated interface and complain if there are any errors. These errors could include calling with the wrong number or types of arguments, or a situation where the language requires an explicit interface but none is provided.

On Windows, Generated Interface Checking is on by default in the Debug configuration of newly created Visual Studio projects. From the command line, you can enable it with /warn:interface on Windows and with -warn interface on Linux and Mac OS. I highly recommend using this option in your builds. It is not perfect, however. In particular, it is sensitive to the order in which files were compiled. If a source that calls a routine is compiled before that of the source that defines the routine, there is no generated interface to check. There can also be an issue if you are editing sources and don't do a "clean" build as there may be an interface from an earlier version of the source still around. And then there are the occasional bugs, though these are rare nowadays.

In summary, it is good Fortran practice to have explicit interfaces for all your procedures. The best way to accomplish this is to have all procedures in modules or as contained procedures if they will be used in limited contexts.

Computed GO TO

This feature remained in the standard through Fortran 95, not deleted until Fortran 2003. but you don't see it very often.  The syntax is:

GO TO (label-list), expr

where expr is an integer expression.  If the expression is 1, control transfers to the first label in the list, if 2, the second label, etc.  If the value is less than 1 or greater than the number of labels, execution "falls through" to the next statement.  For example:

GO TO (10,20,20,30), I

Nowadays the SELECT CASE construct is a preferred replacement.

Arithmetic IF

This is the one I see popping up most often in comp.lang.fortran posts where the author has come across it and has no idea what it does. The syntax is:

IF (expr) label1, label2, label3

Here, expr can be integer or real.  If the value is less than zero, control transfers to label1; if zero, label2; and if greater than zero, label 3. As with Computed GO TO, you can repeat labels if you wish.  Arithmetic IF was declared obsolescent in Fortran 90 and deleted in Fortran 95. The usual recommendation here is to use IF-THEN-ELSE (which was new in Fortran 77).

ASSIGNed GO TO and FORMAT

So let's say you had some common piece of code that needed access to your local variables and that was used in several places in a routine. Nowadays we'd use internal procedures, but before that, there was ASSIGNed GO TO.  The way it would work is you'd declare some integer variable, we'll call it IDEST here, and do something like this:

ASSIGN 30 TO IDEST
GO TO 900
30 CONTINUE
...
ASSIGN 40 TO IDEST
GO TO 900
40 CONTINUE
...
900 CONTINUE
... Do common stuff
GO TO IDEST

The jump to 900 would occur, the common code would execute, and then control would transfer to the label that had been assigned to the IDEST variable.  You could use ASSIGNed variables in place of FORMAT labels too in an I/O statement.

Back when I was working on VAX Fortran, I occasionally encountered programs written by customers who had cleverly noticed that the compiler implemented ASSIGNed GOTOs by simply storing the 32-bit address of the instruction at the assigned label into the variable.  They could then use this address in various ways, perhaps implementing some sort of array of pointers to statements.  (The compiler had to support 16-bit integer variables too, so what it stored there were offsets from the routine start address.)  This unraveled, though, when these applications were ported to the DEC Alpha processors, as the compiler there simply stored an index into a table rather than an instruction address.

ASSIGNed GO TO and FORMAT was declared obsolescent in Fortran 90 and deleted in Fortran 95.

Alternate Return

Here's one that actually stayed in the language through Fortran 95, though it had been named obsolescent in Fortran 90.  Let's say you wanted to call a subroutine but wanted, on return, to branch to some other label if some condition was met, rather than continuing after the CALL. So you'd do something like this:

CALL SUB (arg1, arg2, *10, *20)
...
SUBROUTINE SUB (arg1, arg2, *, *)

In subroutine SUB, you could return normally if you wanted.  But if you wanted to instead return and branch to the first alternate return label, you'd do:

RETURN 1

Similarly, if you wanted to return to the second alternate label, you'd write:

RETURN 2

The value could be any numeric expression that got converted to an integer.  If the value was less than 1 or more than the number of alternate return labels, a normal RETURN would be done.  Some compilers, as an extension, accepted the use of & in the CALL instead of * (but not in the subroutine argument list.)  Intel Fortran also supports that.

Hollerith Constants

FORTRAN 66 didn't have a character data type nor did it have character literals.  Instead, you could use Hollerith constants to assign values to numeric variables.  The form of a Hollerith constant is an integer specifying the number of characters, the letter H, and then however many characters were specified.  For example:

4HABCD

Hollerith constants were odd in that they had no intrinsic data type - they assumed the numeric (remember, no character type!) type based on the context in which they were used.  You could assign Hollerith constants to integer and real variables and the bytes of the characters would be stored directly.  If the constant's length were too short, it would be padded with blanks, and truncated if too long.  Many compilers had the extension of using apostrophe delimited strings as a substitute for Hollerith, so you might see something like:

INTEGER I
I = 'WHAT'

and be perplexed that the compiler accepted it.

Hollerith constants were not carried over from Fortran 66 to Fortran 77, though the 77 standard did have an appendix describing how they should work if a compiler chose to support them.  Note that there is also a Hollerith edit descriptor in formats, but those are treated like character strings and were still in the language through Fortran 90.

Writable FORMAT

This is the language feature that prompted me to write this post.  A user recently complained, in our user forum, that the output of his program was being corrupted by a READ.  In one part of a subroutine he had something like this:

WRITE (6,100) MM,DD,YY
100 FORMAT (I2,'/',I2,'/',I2)

and then later in this same routine:

READ (5,100) I

The first time through the routine, everything was fine, but on the second call, the WRITE had a blank in place of the first slash! What was going on here?

If you're familiar with the interaction between formats and I/O lists, you'll know that once an I/O list item has been "consumed" by an edit descriptor, processing of the format continues until it reaches another data-consuming edit descriptor, a colon, or the end of the format is reached.  So on the READ, processing continues and the '/' is seen.  What does this do on a READ?

In Fortran 77, this is not legal - you are not allowed to have an "apostrophe edit descriptor" in a format used by a READ.  But Fortran 66 did allow this, sort of.  Remember what I wrote above that compilers would treat quoted literals the same as Hollerith constants, so the format was treated as if it had 1H/ instead of the '/'.  Ok, but so what?

Here's where the ancient magic comes in.  Fortran 66 allowed you to READ into a Hollerth edit descriptor, changing the characters for future uses of that FORMAT.  This was usually done to provide titles for reports - you'd read the title from the input card deck (remember cards?) and then the title would appear when the FORMAT was used on subsequent WRITEs.  So what happened here is that a character was read from the input record and it replaced the slash.  In this customer's case, there were no more characters so the input record was padded with a blank.  The FORMAT effectively turned into:

100 FORMAT (I2,' ',I2,'/',I2)

for subsequent calls!  The fix I recommended was to use a separate FORMAT for the READ, rather than sharing the earlier one.

Well, that's enough for today.  Happy New Year, everyone!

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.

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.

Fortran programmers loved the new features of the compiler, but there was some muted grumbling in the background. You see, while it was possible to buy a subset containing C++ and the analysis tools, called Intel® C++ Studio XE, there was no corresponding subset for Fortran-only programmers. Fortran users who also wanted the analysis tools either needed to buy them separately, or purchase the larger Parallel Studio XE product containing a C++ compiler, which, while excellent, might go unused in Fortran-only shops. "Where," you cried, "is our Fortran Studio XE?" Ok, ok. You can put down your pitchforks and Arithmetic IFs – Intel® Fortran Studio XE 2011 is now here for both Linux and Windows!

Intel® Fortran Studio XE 2011 includes the latest versions of Intel® (Visual) Fortran Composer XE (this also includes the Intel® Math Kernel Library), Intel® VTune™ Amplifier XE and Intel® Inspector XE, together at significant savings from buying the tools separately. This corresponds to Intel® Parallel Studio XE 2011 SP1 – we didn't put SP1 on the name of Fortran Studio XE because it's the first release of this combination, and we figured we'd already confused you enough with "Composer". So what's in the box?

Intel® (Visual) Fortran Composer XE

First, of course, is Intel® (Visual) Fortran Composer XE 2011 Update 6. But we've got a special treat or three in here. Normally, you'd expect an Update 6 to be just some minor improvements, including bug fixes, over Update 5, but not this time. Whereas the earlier updates had version 12.0 of the Intel® Fortran Compiler, Update 6 has version 12.1! Yes, it's .1 better! What does this mean for you?

From a programming features perspective, there aren't a lot of new ones in version 12.1. For language standards support, we've added the ability to do an ALLOCATE with a polymorphic SOURCE= keyword. To some of you, that may not seem like much, but many of you who have been playing with the object-oriented features of Fortran 2003 have told us that the lack of this was a serious omission, so now you should be happy. There's also significant run-time performance improvement over version 12.0, especially if you are using the auto-parallel feature. And, of course, the handful (!) of you who have reported problems with the earlier compilers will see that many of your bugs have been fixed.

Windows users, however, have some special added treats. First, we now support coarray programs to run in a distributed mode across a Windows cluster. Not good enough? Ok, for users who don't already have a separate Microsoft Visual Studio* installed, we've upgraded the included Fortran development environment to Visual Studio 2010 Shell! Ok, I see a few more claps for that. Hmm, tough crowd.

So what do you think is the #1 most requested feature from Windows Fortran users in the eight years since Intel® Visual Fortran made its debut? Did I hear "Source Browser?" Yes, that's right! It's baaaack! Now, Visual Studio 2010 users can right click on an identifier and select "Go To Definition", and you'll be taken to the source where that identifier (variable, routine, etc.) is defined, even if it's in a module. "Find All References" is also there. Even better, unlike in the olden days of CVF, you don't have to compile the program first – your sources are automatically scanned in the background while you type.

But wait, there's more! Many of you have been envious of Visual C++ features such as tooltip help for intrinsics, outlining, snippets, etc., and we've added lots of these! I don't have room to go into it all here, but be sure to read the Fortran Composer XE Release Notes for the full list of features we added. One caveat – these features are available in VS2010 only. If you don't have VS2010, you can install the VS2010 Shell from the full product download.

Intel® (Visual) Fortran Composer XE also includes the latest revision of the Intel® Math Kernel Library (Intel® MKL), which has got to be one of the simplest ways of getting screaming performance out of your applications. Intel® MKL has highly tuned and parallelized libraries for BLAS, LAPACK, ScaLAPACK, FFT, vectorized random number generators and much more, all in a well-supported product with royalty-free redistribution rights.

For more information, visit http://software.intel.com/en-us/articles/intel-composer-xe/ and http://software.intel.com/en-us/articles/intel-mkl/

Intel® VTune™ Amplifier XE

If your knowledge of Intel® VTune™ is more than a year old, you will be surprised at what the latest incarnation, VTune Amplifier XE, has for you. If you have never heard of it before, Intel VTune Amplifier is a fantastic performance analyzer that can help you wring the most performance out of your application. Like before, VTune Amplifier XE can use the performance counters in every Intel processor, but it provides easy-to-use wizards for the most common types of analysis, such as "where is my program spending most of its time?" and "where is my program waiting for thread synchronization?"

With VTune Amplifier XE, it's easy to drill down into your sources to see just what is going on and you can sort and filter results so you see just what you're interested in. Linux users no longer require a Windows system to analyze results, you can use a provided GUI on Linux. As always, Intel VTune Analyzer XE supports Fortran as well as C/C++ and, really, pretty much any language that is link/debug compatible with the Intel compilers. Learn more at http://software.intel.com/en-us/articles/intel-vtune-amplifier-xe/

Intel® Inspector XE

As the old saying goes, it doesn't matter if you get fast results if they're the wrong results. Intel® Inspector XE, previously available only to C/C++ users, now adds Fortran support. It provides powerful and easy to use correctness checking that works across the whole program. There are three main parts to Intel® Inspector XE.

First there is "memory checking", which looks at your running program for memory issues such as memory leaks, accesses through dead pointers, memory corruption and more. Second is "thread checking", which looks at your threaded program (using OpenMP, Windows API threads or pthreads) to see if there are deadlocks, data races and other threading errors that can be very hard to debug.

The third feature, Static Security Analysis, works in conjunction with the Intel compilers to do whole-program correctness checking for issues such as uninitialized variables, misused OpenMP* directives, array bounds errors (even in Fortran code where run-time bounds checking can't be used), and more. With Static Security Analysis, you do a special compile-only build of your application using the Intel compilers and then analyze the results using Intel Inspector XE. Note that you are free to use a different compiler to build the application, but the Intel compiler is used for Static Security Analysis reporting. I should also point out that Static Security Analysis (SSA) is a "suite-level" feature that requires a license for one of the "Studio" products. SSA is not available if you license Composer XE and Inspector XE individually.

For more information on Static Security Analysis, see http://software.intel.com/en-us/articles/static-security-analysis/ and for information on Intel Inspector XE, see http://software.intel.com/en-us/articles/intel-parallel-studio-xe/

Conclusion

So there you have it – Fortran users no longer need to feel slighted as they have an Intel software development suite of their very own. Sweet!

Don't panic - I'm not going very far! Intel is moving us from our Nashua site to a new site in Merrimack, the next town to the north. The new place is said to be quite nice - I've driven past it and it is much closer to my home - but the 110 Spit Brook Road site in Nashua has a lot of memories.  Yes, this is indeed going to be another retrospective post. If those annoy you, you can stop reading now.

I have a deep connection to this set of buildings.  I've been here longer than anyone else, moving in with the VMS developers in July 1980.  My fellow languages people did not show up until a couple of months later.  Also, I had a hand in naming the conference rooms in the third building (added in 1986), and added an item (a copy of Charlie Andres' CPU Wars) to the time capsule that was buried in the walkway outside the first building. (That capsule was to be dug up in 1996, but it was found to have let water in and the contents destroyed.)

In 1979, DEC decided that it wanted a dedicated software engineering site and broke ground in a heavily wooded section of south Nashua, off a street that changed to a dirt road just past the access road.  Spit Brook Road was (and is) that street, and the name has been the subject of confusion and incredulity over the years.  Variously misstated as "Spitbrook" or "Split Brook", it is named after a small stream that runs through the woods.  This part of Nashua has grown incredibly over the years, with shopping malls, restaurants, housing developments and traffic - lots of traffic.  Needless to say, Spit Brook Road is now paved all the way down.

At the time, DEC used two-letter site codes.  I was currently working at the Tewksbury, Massachusetts site, which, like many DEC sites, was a converted shopping center. Tewksbury was code TW, not unreasonably.  The obvious choice for the new site was SB (variations on Nashua, such as NU or NS were already taken - DEC had three other Nashua sites), but the corporation had decided that it was going to reserve all future S codes for sales offices.  For reasons that escape me, new sites were being given codes starting with Z, and the Spit Brook Road site got "ZK".  We all wanted to know what ZK stood for, and Joy Marshall, the VMS group admin, announced that it meant "Zonker Kookies".  And so it was.  Shortly after that, DEC changed to three-character site codes and added the letter "O" to existing sites, so it was now ZKO.

A striking feature of the first building was the "barcode wall" at the main entrance.  In its original form, the background was painted the same bright red-orange that VMS documentation binders were using, and on that was a set of 182 black and white bars, in thirteen groups of seven bars in two rows.  If you interpreted the black bars as ones and the white bars as zeroes, they spelled, in ASCII:

digitalsoftwa
reengineering

Some years later, a manager decided on a different message.  The background was repainted gray (the binder color now) and the bars rearranged to spell:

customers win
whenwedeliver

Amusingly, two of the bars in the lower row got switched so that two of the characters are wrong.  It was never fixed.  Here's what it looked like in 2006.  Click to get access to larger sizes.

Over the years, DEC's software portfolio grew and so did the Spit Brook site.  In 1982 a second building was added to the right, and in 1986, a third to the left. The languages group, among others, moved to "ZKO2", and the VMS and UNIX groups moved to ZKO3.  An interesting aspect of these buildings was that the ground floor for buildings 1 and 2 was in fact the third floor.  The land dropped off behind the building, so you would go down to floors 2 and 1.  Building 3 was built with four floors, and was oriented 90-degrees from the others. There you entered on the second floor.  Behind the site, visible from the cafeteria, was a pond dubbed the "Non-Paged Pool" (another VMS joke).

Today, things are quite different.  DEC gave way to Compaq, which was in turn swallowed by HP.  Intel bought part of the languages group from Compaq and walled off our section of ZKO2.  HP later moved everyone out and sold the site to a local real estate developer, who has brought in several other companies in various parts of the buildings.

So now we're moving - and we are provided three plastic bins in which to place what we want moved.  Many of us have been here for many, many years and have of course accumulated a lot of - um - stuff.  I decided to be quite ruthless in determining what to keep and what to discard. Some things, such as the "VAX FORTRAN for ULTRIX Installation Guide" were easy to get rid of.  Other things were not.  I wanted to share with you a few of the things I chose to keep.

First up is this poster, which I saw displayed when I interviewed for DEC in August 1978.  I loved it and when I got a chance to acquire a copy from a developer who was going to discard it, I grabbed it.  It would have been good again in 2006, but I missed it.  Next up is 2034.

Then there's the red, white and blue "FORTRAN FOR PRECEDENT" campaign button, the lyrics to "VMS Superlate", a skit put on by the VMS team back in, I think, 1984, in honor of the delays in getting the next version of VMS out the door.  A sample (tune of "Jesus Christ, Superstar"):

VMS, Version Three
How much longer is it gonna be?
VMS, Superlate
Keep on coding, let the bas****s wait

I also found my binders of SPRs (customer bug reports) from my early days on the VMS Run-Time Library.  There was a special one I wanted to share with you here (PDF).  Note that the customer rated this as "Priority 1 - Heavy System Impact".

What really makes me feel old is realizing that I have coworkers who weren't even born when I moved into Spit Brook in 1980. I've been here more than 30 years, and in the same cube since 1988.  Lots of good memories and good products (VAX Ada! Digital Visual Fortran!) and some bad memories (layoffs, untimely deaths of coworkers (Simon Szeto, Lily Lanza, Dick Hustvedt)), but overall I'll miss this place.  Now we will make new memories at the new site, dubbed Heron Cove (the name of the office park it's in.)  And of course, lots of great new products!

For version 11.0, I took one of the old Microsoft samples, a Win32 program called Angle, and tried to clean it up.  The original coding style had used a series of external procedures and multiple copies of INTERFACE blocks to declare other routines.  As I've written elsewhere, I consider this poor Fortran style - if you think you need to write an INTERFACE block for a Fortran routine, you're doing it wrong - so I rewrote this as a single WinMain entry function and a series of contained routines.  This means that all the interfaces were explicit without the need for INTERFACE - great!  It built fine on all platforms and ran ok, so it seemed, at least on IA-32, so I checked it in.

Since it is a "Windowing application", it needs to "register" with Windows the addresses of various routines that handle dialogs and Windows "messages", for example, "create a window", "repaint window", etc.  This is done by passing LOC(routine-name) to the API routine, or in some cases, assigning that value to a member of a data structure.  Here's where I ran into trouble.

In Fortran 2003, it's not allowed to pass an internal procedure as an actual argument as the simple method of doing this, just passing the address of the routine's entry point, doesn't provide the context necessary for up-level references to the caller's variables.  The standard does say, however, that if an implementation supports this, it must do it so that the internal procedure uses the dynamic context of the "invocation" that passed the routine as an argument. Here's an example:

program thunk
implicit none
call callit
end

subroutine callit
integer localvar
localvar = 1
call extsub(intsub) ! Extension!
localvar = 2
call extsub(intsub) ! Extension!

contains

subroutine intsub
print *, localvar
end subroutine intsub

end subroutine callit

subroutine extsub (subname)
external subname
call subname
end subroutine extsub

Intel Fortran (and DEC/Compaq Fortran before that) supports this as an extension, and this feature is part of the upcoming Fortran 2008 standard, so I felt it was ok to use the feature. Or at least I thought I was using it...

Now, you may be asking, how does this work?  How can a single address contain both the actual entry point and the "dynamic context" needed to get at the specific invocation's variables.  The answer is what is popularly called a "thunk".

The actual implementation of thunks varies - what I will describe here is a generic method that may or may not match what actually happens.  The concept is the same, though.

First, the compiler has to know that it needs to set things up so that some routine called later can access its local variables.  It arranges these variables in a section of stack (usually) and generates the address to the start of the section.  Let's call this address SF (for Stack Frame).  It then constructs a mini-procedure that does something like this (pseudocode ahead):

LOAD Register1,SF
JUMP ActualInternalRoutine

and then saves the address of this mini-procedure, the "thunk".  It is this address that is passed as an actual argument, so when the routine is called through the reference, the stack frame context is loaded into a register and then the real routine executes, knowing that the context has been set up.  (If it were being called directly, the caller would establish the context first.)  The internal routine then uses the context to find the local variables of the "invocation" that created the thunk.  Neat.

Historical note: in the past, these thunks were built on the stack, which was very convenient.  However the notion of executable code on the stack was also convenient for virus writers so operating systems evolved to disallow this.  Other solutions were found, a topic for someone else's blog.

Ok, back to the story.  During the release process for 11.0, one of our team of crack Product Validation engineers discovered that the Angle program didn't work on the Intel® 64 platform. When run, the program just exited immediately, never producing any error message or display.  I was chagrined, as I should have tested it on all three platforms.  I spent quite a while trying to figure out what was wrong, getting nowhere.  I put it aside.  Luckily, a few months later, another of our engineers was playing with this and also noticed the problem.  Even better, he was able to figure out what was going wrong, which enabled me to fix the problem.

Remember when I said that I "thought" I was using the extension allowing passing of internal procedures?  Well, that wasn't really what I did - I used LOC(procedure), which is not the same thing!  This simply provides the address of the actual routine's entry point, it does not create a thunk!  So, if the internal procedure ever tried to reference an up-level local variable, it would be doing so through an uninitialized context pointer and trashing memory!

Ok, but were there any up-level references?  Yes, as it turned out, though not deliberately.  The unnamed Microsoft coder had been sloppy and not explicitly declared all local variables: in particular, variables named ret and lret used to hold return statuses.  Of course, IMPLICIT NONE wasn't being used either.  No real harm done, in the original code, since these values never got used.  But when I moved these routines into internal procedures, it turned out that variables of these names were declared - in the host scope!  Even the IMPLICIT NONE I added didn't help here - those assignments became up-level references automatically.

The fix was to add local declarations of the appropriate variables, eliminating all up-level references.  I also asked that the compiler complain if a LOC was done of an internal procedure that contained up-level references - this should appear in a future update.

But wait, there's more to this story.  What if LOC had created a thunk rather than just a routine address?  There's no reason why not, right?  True.  However, even if it had, I would have run into another problem which can affect any call where information about arguments is saved for later.

The structure of this code had two worker routines, MainWndProc and DlgProc.  Both of these are called asynchronously by Windows to handle various events.  At one point in MainWndProc, it passes LOC(DlgProc) to a Win32 routine (CreateDialogParam) and then returns.  What happens to the thunk when MainWndProc returns?  It's gone since the invocation that created it has returned.  The place in memory where it resided may or may not still contain valid contents.  If the thunk is then called through, there can be unexpected behavior including access violations or data corruption.  Not nice.

This type of error affects many different kinds of programming where side-effects happen sometime after a call completes.  Fortran 2003 introduces (and Intel Fortran supports) the concept of asynchronous I/O, where you begin an I/O operation and then return to the program flow, expecting the variable to be filled in (or written out) later.  It is important that the variable remain "in scope" until the I/O completes, otherwise nasty errors can occur.  You can see similar effects with the popular MPI distributed processing library where you "send" and "receive" data asynchronously between independent executions of code.  Again, you must make sure that the variables used asynchronously stay defined until all operations are complete.

Going back to Angle, what if I had wanted the address of a thunk rather than that of the actual routine?  I could create a function to do that like this:

function thunkloc (proc)
integer(INT_PTR_KIND()) :: thunkloc
external proc
thunkloc = loc(proc)
return
end function thunkloc

Angle has been corrected for Update 2 of Intel Visual Fortran 11.1 and I have learned my lesson (I hope) about not assuming too much and being sure to test thoroughly!

Look, But Don't Touch

Consider the following subroutine:

subroutine sub (i)
integer i
if (i > 2) i = i + 1
return
end

Now, what happens when you call this with:

call sub(3)

???

a) The value 3 changes to the value 4 in the caller
b) Access violation or segmentation fault
c) Nothing, the variable changes value in the subroutine but not the caller
d) World War III starts

The answer, for many older compilers, was (a)!  For current Intel compilers, the correct answer, however, is (b) - a run-time error that is "access violation (on Windows) or "segmentation fault: on Linux and Mac OS.  Why?  The compiler has to put the value 3 in memory somewhere.  By default, it puts it in a section of memory it has asked the operating system to make "read-only". When the value of variable i changes in the subroutine, that is an attempt to write to read-only memory and you get a run-time error.

The Intel compiler has an option, /assume:[no]protect_constants (Windows) or -assume [no]protect_constants (Linux/Mac OS) which can change this behavior to (c). If "noprotect_constants" is specified, then the compiler creates a temporary copy of the value 3 and passes the address of the copy.  The subroutine can change the value all it wants but the changes will be discarded on return.  (Those who have been with the Doctor for a long time may recall that I wrote about this back in the CVF days, almost nine years ago.  You can read that item here.

I will point out now that the above call is not legal Fortran - the literal constant 3 is not "definable" and that means you are not allowed to "redefine or cause to become undefined" the associated dummy argument. However, code like this has appeared in many applications over the years.

Now, what if you did this?

call sub((3))

What is being passed  here is an expression, not a literal, so is that legal?  No!  An expression is not definable either!  However, Intel Fortran treats this differently and will always pass a temporary copy of the value, as if you had said /assume:noprotect_constants.

But what if you wanted to pass any variable to this subroutine but have the original value preserved?  You could write:

call sub((j))

and take advantage of Intel Fortran's extension where it passes a copy, but Fortran 2003 has another way. If you give the dummy argument the VALUE attribute, which requires an explicit interface to be visible, then the effect is similar in some ways to passing an expression.  Actually, what happens is that on entry to the subroutine, a new local variable is created that copies the value of the argument, and all references in the subroutine are to that local variable, which is definable.  On exit, like other local variables, the copy is discarded. VALUE has another purpose as part of C interoperability, but I'll discuss that another time.

By the way, there's a less obvious way that you can pass an argument that is not definable: an array with a vector subscript.  For example, A([1,3,5]).  Here too, you're not allowed to assign into a dummy argument that is associated with such an actual argument.

Alias Smith and Jones

It is often said that Fortran is faster than C because Fortran disallows variable aliasing, where the same storage can be referred to by two or more different names, and in C everything can be aliased.  There is some truth to this on both sides, but it is not absolute - especially when more recent versions of the C standard are considered.

It is true that in most cases, a Fortran compiler can assume that no aliasing occurs, but not always.  Unfortunately, a lot of programmers inadvertently violate the language rules and run int trouble. Here's the basic text that the standard has to say about aliasing:

While an entity is associated with a dummy argument, the following restrictions hold:
(1) Action that affects the allocation status of the entity or a subobject thereof shall be taken
through the dummy argument. Action that affects the value of the entity or any subobject
of it shall be taken only through the dummy argument unless
(a) the dummy argument has the POINTER attribute or
(b) the dummy argument has the TARGET attribute, the dummy argument does not
have INTENT (IN), the dummy argument is a scalar object or an assumed-shape
array, and the actual argument is a target other than an array section with a vector
subscript.

[12.4.1.7 Restrictions on entities associated with dummy arguments]

Let's look at the simplest example:

program alias1
real x
x = 4.0
call sub (x,x)
print *, x
end

subroutine sub (a,b)
real a,b
a = a + 2.0
b = b * 3.0
return
end subroutine sub

What does this program print?

a) 6.0
b) 8.0
c) 12.0
d) 18.0
e) Any of the above

The correct answer is (e).  The program is not legal Fortran and the results are unpredictable.  For example, the compiler could do either the add or the multiply first, or it could copy the values of the arguments into a temporary (say, a register), do the add/multiply, then store the result.

Ok, that one is pretty obvious.  How about this?

program alias2
real x
common /CMN/ x
x = 4.0
call sub(x)
print *, x
end
subroutine sub (y)
common /CMN/ x
real x,y
y = y + 2.0
x = x * 3.0
return
end subroutine sub

The choices, and answer, are the same as for alias1 above.  Here, the aliasing is between a dummy argument and a COMMON variable.  As of Fortran 90, you could extend this case to module variables or host-associated variables in addition to COMMON.  It's ok if all you do is get the value, but once you change the value (or change the definition status), then the requirement is that all such changes must be through the dummy argument only.

This second scenario is much easier to stumble into, especially with large applications.  Recognizing this, the Intel compiler has an option to tell the compiler to assume that such aliasing may exist and to disable optimizations that depend on the absence of aliasing.  That option is /assume:dummy_aliases (Windows) or -assume dummy_aliases (Linux and Mac IOS).  If you have an old and large program that isn't getting correct answers, try enabling this option to see if it helps.  In many cases, it will.

In Conclusion

Wow, this has been one of my longer posts, and there's lots more that could be said on the general topic of arguments, but we'll save that for another time.

If you have a comment on this article, or a suggestion for a future topic, feel free to add a comment here. (If you need technical support, please visit our user forum instead.)   Also, you can now follow me on Twitter, if you're so inclined: @DoctorFortran I'm still feeling my way with this "fluttering" thing, so be kind...

write (30,'(2x,f8.2)') array

and he was dismayed to find each element written on a new line.  He had then tried this variant:

write (30,'(2x,f8.2)',advance='no') array

reasoning that the "advance='no'" would prevent the new lines.  No good - still one element per line.

Another user suggested this:

write (30,'(2x,(f8.2))') array

but this was worse in that the first line had two spaces before the number but subsequent lines did not.

What's happening here?  What is the best way to write a format that will give a specific format to a variable number of values?

Bouncing off a hard, rubber wall

The odd behavior is due to a little-understood Fortran language feature called "format reversion".  This dates back to at least Fortran 77, if not Fortran IV, and specifies what happens when you get to the end of the format but still have items to process.  A new record is started, (technically, it behaves as if a '/' edit descriptor was processed), and "format control then reverts back to the beginning of the format item terminated by the last preceding right parenthesis... If there is no such preceding right parenthesis, format control reverts to the first left parenthesis of the format specification."

If we take the original format above,

'(2x,f8.2)'

and assume that the array has three elements, this ends up being equivalent to:

'(2x,f8.2/2x,f8.2/2x,f8.2)'

because there is no preceding right parenthesis, so control reverts back to the beginning of the format and three records will be created.  Even if advance='no' is added, we'll get three records because "non-advancing I/O" is about what happens at the end of the I/O statement, not the middle of it.

Now let's look at the proposed fix:

'(2x,(f8.2))'

This ends up being equivalent to:

'(2x,f8.2/f8.2/f8.2)'

as the end of the (f8.2) group is the preceding right parenthesis, so we revert to the beginning of that group. By the way, if there is a repeat count on that group, then the repeat count gets reused.

What to do, what to do

In Fortran 2003, there's no really good way of generally attacking this problem.  If you have an idea of an upper limit for the number of elements, you could specify a large repeat count on the group, such as:

'(1000(2x,f8.2))'

This assumes there won't be more than 1000 elements, but is somewhat ugly.  And no, you can't put a PARAMETER constant in for the 1000.  Some people will suggest that you construct a format at run-time by writing into a character variable and using a run-time format, like so:

character(80) :: fmt
...
write (fmt,'(A,I0,A)') '(',n,'(2x,f8.2))'
write (30,fmt) array

where "n" is the number of elements in the array.

Another option is to use an extension called Variable Format Expressions (VFEs).  This was created by DEC in the 1970s and it earned the enmity of Fortran compiler writers everywhere who were pestered by their customers to support it as well.  With VFEs, you can enclose an integer expression in angle brackets and the value of the expression will be used in the format.  For example:

write (30, '(<n>(2x,f8.2)') array

Intel Fortran, of course, given its DEC heritage, supports VFEs, but I don't recommend their use if you have other reasonable options.

Look to the future

Fortran 2008 solves this problem with a feature called the "unlimited format item" where a * can be used as a group repeat count.  Its effect is "as if its enclosed list were preceded by a very large repeat count".  For example:

'(*(2x,f8.2))'

This lets you avoid having to write a specific large number as the repeat count and makes it more obvious what is going on.  Intel Fortran does not support this yet.

The Doctor's advice, should you find yourself in this situation, is to use the large repeat count, at least until the compiler you use supports the unlimited format item.  You may find some cases where VFEs simplify your coding, so feel free to use them if there is no reasonable standard-conforming alternative.

Got suggestions for future Doctor Fortran columns?  Let me know!

First, some terminology.  In Fortran, there are "actual arguments" and "dummy arguments".  An actual argument is what you put inside the parentheses in a call to a procedure.  This can be a variable, a named (PARAMETER) constant, a literal (such as 3), a procedure or an expression. "variable" here means more than just a variable name. It could be an array reference, a derived type component reference, a substring reference or a combination of any or all of these.  If you can put it on the left side of an assignment, it's a variable.

A dummy argument is the corresponding element in the argument list of the called procedure.  Some languages call these "formal arguments". When you call a procedure, each dummy argument becomes "associated" with its corresponding actual argument, if any.  (OPTIONAL dummy arguments do not get associated with omitted actual arguments.)  The rules for argument association are complex and have many special cases, and that's what I'll spend most of this post going over.

Argument Association

On a fundamental level, argument association is pretty simple.  Although most people would tell you that Fortran uses "pass by reference", meaning that the address of the actual argument is used for the dummy argument, that's not quite true.  The standard says that argument association is "usually similar to call by reference" and then adds "The actual mechanism by which this happens is determined by the processor." [Fortran 2003 Note 12.22]

There are some cases where what actually gets passed is not the original argument.  The most common case for this is when a non-contiguous array pointer or a array slice is passed to an argument for which the compiler does not see an explicit interface specifying that the corresponding dummy argument is an assumed-shape array.  Because the called routine is expecting a contiguous array, the compiler needs to make a copy of the actual argument, pass the copy, and then copy back any changes. The compiler can warn you about this at run-time if you use the option /check:arg_temp_created (Windows) or -check arg_temp_created (Linux/Mac OS). The compiler will generate a run-time test to see if the argument is actually contiguous and skip the copy if it is.

This would probably be a good time to mention INTENT.  If the compiler sees that the dummy argument is INTENT(OUT), it doesn't need to make the copy going in, and if it is INTENT(IN), it can skip the "copy out".  Explicit interfaces and explicit INTENT are always a good idea.

Another case where a copy is made is if the argument has the VALUE attribute.  By this I mean the Fortran 2003 VALUE attribute, not the one on a !DEC$ ATTRIBUTES directive.  In this case, the copy is made by the called routine on entry into a temporary, and any changes discarded on exit.

Sequence Association

A lot of Fortran programs, especially older ones, rely on sequence association.  What is it?  An actual argument that is an array element, an array expression or a character scalar (of default or C_CHAR kind) represents a sequence of elements.  This sequence starts with the first element or character passed and continues to the end of the array or last character.  The corresponding dummy argument, which need not have the same number of dimensions (rank) as the actual argument, or the same character length, is associated with this sequence.

Let's take a simple example common to older code.

real a(10)
call sub(a(3))
...
subroutine sub (b)
real b(8)

When sub is called, b(1) will be associated with a(3), b(2) with a(4) and so on up through b(8) being associated with a(10).  Usually, the programmer would declare b as assumed-size with a dimension of (*), in which case the implied extent of b is 8 because that's the number of elements remaining in array a.

What happens if you declare b to be fewer or more than 8 elements?  Fewer is fine, but more is not.  The compiler may or may not detect this error.

There is a significant restriction regarding sequence association which more and more people are running into, especially as they "update" old code to include modern Fortran features such as pointers.  You don't get sequence association if the actual argument is assumed-shape or is an array with a "vector subscript".  Why?  Because the argument may not be contiguous and thus there can't be an association with a sequence of elements.

Here's where this gets most people into trouble... In general, a Fortran rule says that "if the actual argument is scalar, the corresponding dummy argument shall be scalar, unless the actual argument is of type default character, of type character with the C character kind, or is an element or substring of an element of an array that is not an assumed-shape or pointer array." [Fortran 2003 12.4.1.2]

If in the example above, array a was an assumed-shape array (might be a POINTER or ALLOCATABLE or a dummy argument itself) and you passed a(3), the compiler would give you error #6585 quoting the text from the standard shown in the previous paragraph. The workaround for an assumed-shape array would be to pass an array slice, but you can't then depend on sequence association and the dummy argument has to be no larger than the slice you passed.

You'll also get this error (as error #8299) if you are passing a scalar that isn't an array element, such as a constant 1 or a scalar variable, to an array dummy argument.  In some cases you can use an array constructor to turn the scalar into an array, such as [1], but you will lose sequence association benefits.

Now, what's the deal with that exception for character types when the dummy is an array of default character kind or C kind?  This lets you pass a normal character value or variable to a dummy argument declared as an array of single characters, as this is the official "interoperable" mapping for C arguments declared as "char*". Note that you'll have to supply any trailing NUL yourself - Fortran won't do it for you.

Rules, Rules, Rules

Here are just a few of the other language rules that must be followed when passing arguments. You can read them all in section 12.4.1.2 of the Fortran 2003 standard.

• The types of the actual and dummy argument must be "type compatible",  Typically this means the same type, though things start to get fuzzy when the Fortran 2003 feature of "polymorphism" comes into play (coming soon to Intel Fortran.)
• If the actual and dummy are character scalars, the length parameter of the actual must be greater than or equal to the length parameter of the dummy, if it is not passed-length.
• If the dummy is a pointer, the actual must be too. Same goes for allocatable.

The compiler can help a lot with making sure the rules are followed if you are using explicit interfaces (modules, contained procedures or INTERFACE blocks.)  Otherwise, use the /warn:interface and /gen-interface (Windows), -warn interface and -gen-interface (Linux, Mac OS) options to have the compiler do interface checking for all your Fortran routines.  On Windows, these options are enabled by default in new Visual Studio projects.

My advice is to always use explicit interfaces and to use proper INTENT attributes as well.

That's all for this round. If you have comments on this post, please add them below.  If you are looking for tech support, please post in our user forums.

Department of Redundancy Department

This is an oldie but a goodie.  If one declaration is good, two should be better, right?  I've seen some programs come in with such things as:

INTEGER I
INTEGER I

Whatever possessed them to write this, I don't know.  In some cases, there isn't even the excuse of one of the declarations coming from an INCLUDE file.  So what's wrong with this?  The Fortran 2003 standard says:

C508 An entity shall not be explicitly given any attribute more than once in a scoping unit.

The C508 indicates that this is a "constraint" - a rule that must be followed in order for the program to be valid standard Fortran and which the compiler must have the ability to check.  Some compilers will allow this redundant declaration (when not asked to check standards conformance), but Intel Fortran does not.  We've had requests over the years to be more relaxed here, but we believe that such redundant declarations are more likely to be an unintentional error.  For example, we sometimes see declaratioins such as the following:

INTEGER X1,X2,X3,X3,X5

where it seems clear that the programmer meant to declare X4 but slipped. We'd rather alert the programmer to the error than have it go undetected and possibly cause problems later.

Up Periscope!

Fortran 90 added several more "scopes" - nested contexts where symbols can be found.  The "host scope" is the traditional Fortran 77 one which is within a given program unit (subroutine, function, program or BLOCK DATA construct).  "use association" comes into play when you have a USE of a module, and the module has its own scope. "host association" is when one scope is contained within another, such as a module procedure or a contained procedure.

Here again, it's possible to get into trouble by adding a declaration that doesn't need to be there. Consider the following case:

module MYMOD
implicit none
contains
integer function F1 (X)
integer, intent(IN) :: X
integer F2
F1 = F2(2*X)
end function F1
integer function F2 (X)
integer, intent(IN) :: X
F2 = 3 * X
end function F2
end module MYMOD
 

When this code is built into an application using version 11 of the Intel compiler, a link error is generated for the call to F2 from within F1; an error that did not happen with version 10.1.  Compiler bug?  No, a compiler bug fix - version 11 is correct.

The trouble-maker is the "redundant" declaration of F2 inside F1.  Without that, F2 already has an explicit interface from host association - it is a module procedure in the same module.  But if you then add a declaration of F2 inside F1, the language says that this is declaring a different, external procedure F2, which may or may not exist in the program.

The key part of the standard governing this is Fortran 2003 section 12.4.4, "Resolving named procedure references".  It is essentially an algorithm to follow to determine which F2 is meant when you have a reference to a procedure F2. If you follow the steps using the above example, you'll find that you end up at 12.4.4.3(3) "the reference is to an external procedure with that name".

This is not restricted to procedures, though.  Consider the following:

module MYMOD2
integer X
contains
subroutine SUB
integer X
X = 3
...
 

If you are expecting the module variable X to be updated when SUB is called, you'll be disappointed.  In general, local declarations of a name hide host-associated declarations of the same name.  But if you're expecting that behavior for use association as well, think again...

module MYMOD3
integer X
end module MYMOD3
subroutine SUB
use MYMOD3
integer X ! Error!
...
 

This redeclaration of X is an error; unlike for host association, you can't hide a use-associated name with a local declaration.  If you want to do that, then use an ONLY or renaming clause to prevent the same-named symbol from becoming visible.

We often see these sorts of problems in code that has been "converted from Fortran 77" by taking a set of procedures and putting them in a module.  Declarations which were necessary in the separate context are forbidden when host association comes into play.

One More Thing

Finally, consider this example:

module MYMOD4
integer X
end module MYMOD4
program MAIN
use MYMOD4
dimension X(10)
...
 

This is also an error.  Once you inherit a symbol through association, most of its attributes are "locked"; you are not allowed to add to them.  An exception is made for the ASYNCHRONOUS and VOLATILE attributes which can be added-on inside a procedure.

Say No More

Now you have learned that, while it is good practice to explicitly specify attributes, you can get into trouble by over-doing it.  I hope this has helpful to you.  Feel free to comment below if you have questions about this item, but if you are looking for support for a problem, please ask in the user forums instead.

It was the morning of October 2, 1978 when I walked into DEC's facility in Tewksbury, Massachusetts.  Like many DEC facilities at the time, it was a converted shopping center.  The main building used to be a Caldor department store and across the parking lot a secondary building had been an A&P grocery store. The TW facility, as it was then known, was DEC's first engineering site outside the immediate area of Maynard, Mass., and most everyone there had formerly been at DEC's Maynard headquarters called "The Mill". (It was a former woolen mill.)  Hanging up inside was a big banner: "Welcome to Andover Street!", an attempt to make the relocated employees think that they were still in the Maynard area, instead of about 30 miles to the north.

When I had interviewed at DEC a couple of months earlier, I had apparently drawn the interest of both Rich Grove, who headed the VAX-11 FORTRAN-IV-PLUS project, and Tom Hastings who headed the VAX Run-Time Library team.  They compromised - Tom would hire me, but I'd be assigned to work on the Fortran run-time library.

DEC had just launched the first VAX, the 11/780, and VAX-11/VMS Version 1, in August, and it was proving very successful already.  The Fortran compiler was derived from the FORTRAN-IV-PLUS compiler for the 16-bit RSX-11 OS on the PDP-11 series and was, in that first version, a cross-compiler, running in 16-bit "compatibility mode" but generating native 32-bit VAX code.  It was a FORTRAN-66 compiler with many F77 features, and I was tasked to design and implement the run-time library support for the remaining F77 features such as INQUIRE and "OPEN on a connected unit" (holding my nose on the latter.)  I also worked on support for NAMELIST, a popular IBM Fortran feature we wanted to copy.

VAX FORTRAN V2 (the -11 and the -IV-PLUS were dropped) came out in 1980 and was a full-language F77 compiler. By that time, I was working on the VAX Pascal V2 project.  V1 had come from the University of Washington, but V2 was a complete rewrite with a new code generator and a new run-time library, which I wrote the spec for and then implemented.

1980 is also when DEC's new Software Engineering facility on Spit Brook Road in Nashua, NH opened. I moved there with the VMS group in July of 1980 and the languages group joined me a few months later. DEC added a second building in 1982 and the languages group moved there.  ZK2, as it was known, has been my (work) home since then - I think I've had only two offices in that 26 years, and I have been in the current one since 1988.  A third building was added in (I think) 1985 and the VMS group moved to its fourth floor (the other two buildings had only three floors.)  The Spit Brook Road facility is famous (in some circles anyway, including the "ZK" adventure game), for the giant barcode on the building 1 entrance wall.

In 1983 I left the Run-Time Library group and joined Charlie Mitchell's VAX Ada team, as project lead for a new embedded and real-time variant called VAXeln Ada.  VAXeln was Dave Cutler's last project before leaving DEC for Microsoft and was a modular real-time OS that ran on VAX hardware.  (I was pleased to note that the VAXeln team, while they had written their own Pascal compiler, ported my VAX Pascal library to use with it.)  VAXeln Ada was modestly successful, but its being tied to the VAX hardware limited it in the market over the long term.

In 1988, I returned to Fortran and joined Kevin Harris' VAX Fortran compiler team, actually working on a compiler for the first time.  Over the next few years, some of the team migrated over to Stan Whitlock's  "DEC Fortran 77" for the short-lived DECstation line (MIPS processor, DEC ULTRIX OS), and later for both VMS and DEC OSF/1 (UNIX) on the new DEC Alpha processor. A separate team under Keith Kimball was working on a new Fortran 90 compiler which became DEC Fortran 90 in 1993.

In 1993, we released VAX Fortran V6, which incorporated the auto-parallelization and auto-vectorization features of VAX Fortran HPO (High Performance Option), marketed as an add-on to VAX Fortran V5 (even though it was actually a separate and derivative compiler).  It was at this time that I became the entire VAX Fortran project, adding such features in the coming years as uninitialized variable detection, recursion and pointers.

By 1997, VAX Fortran was pretty much in "maintenance mode", so my attention switched to the upcoming DIGITAL Visual Fortran (DVF) release, launched in March 1997.  In many ways, we had no idea what we were getting into here, it was an entirely new market for a team used to selling compilers for tens of thousands of dollars to large institutions and with an established (and expensive) support infrastructure.  With DVF, we were selling a compiler for $599, sold direct by resellers and without the normal DEC support structure.  We created our own support methods, including email submission and tracking reports using the DEC NOTES tool and some DCL (VMS scripting command language.)  To say that results exceeded our expectations would be an understatement. None of it would have happened without the vision and determination of William Youngs, the Fortran project's supervisor at the time, who developed the idea and ran with it. William is retiring from Intel now and I will miss him greatly.

While I was still doing compiler development, and was "sub-project leader" for the VMS Fortran compiler, more and more of my time was invested in "community outreach"; developing the DEC Fortran web site, contributing to an email newsletter, writing FAQ articles and participating in comp.lang.fortran.  Compaq's purchase of DEC in 1998 didn't really change much for us - we got new badges and changed the color of the boxes.

One day in June, 2001, I found two curious messages in my email inbox.  One was addressed to all Compaq employees at the Spit Brook Road site, inviting them to a meeting in the cafeteria.  But another, addressed to fewer, instructed us to go to the site auditorium instead.   This is where we learned that Intel was acquiring Compaq's Alpha processor technology team (if they wanted to join). Nobody at our facility was involved in that, except..  Intel also wanted the Fortran team as well as much of the C++ team, and we were being offered positions with Intel.  There was a lot unknown, but all of us saw which way the wind was blowing and accepted the offers.  Our formal start date with Intel was August 16, 2001 and we walled off our section of offices to form an "Intel Inside" area.

It was less than a month later that we woke up to learn that HP had bought Compaq, and the buildings became an HP site (with our Intel section.)   Towards the end of 2007 HP started moving employees out of Spit Brook and by July 2008, they were all gone. The buildings are now owned by a local real estate developer and have sections leased by various companies including Dell (formerly EqualLogic), Skillsoft and Amphenol. Even the street address has officially changed: we are now "300 Innovative Way" (yuck!)

At DEC/Compaq, we had a small team (perhaps 20 if you count the code generator/optimizer developers), and that included development, marketing and support.  Intel was structured very differently, with separate teams for front-end (language-specific), back-end (code generation and optimization), support, testing, packaging and marketing. What I was doing by 2001 was much more aligned with the support team than with development, so in mid-2002 I formally switched groups and joined Joe Wolf's Intel compiler support team, based in Hillsboro, Oregon.  I stayed put in my office, though, and continued to sit and interact daily with the developers in Nashua.

And that's pretty much the way it is today.  I do a lot more support coordination and "evangelism" (such a trendy term) nowadays than in the past and not much development. I also travel and meet customers much more than before.  Every once in a while I get to play; writing code samples or helping the developers by writing some prototype code, but officially my coding pencil was retired some six years ago.

What is truly astonishing in this day and age is that many of the developers who surround me have DEC histories almost as long as mine, and some are even longer.  They're a wonderful gang to work with and I enjoy being here each and every day.

J3 meets four times a year; for a long time now, two of the meetings have been held in Las Vegas (inexpensive hotel rooms and good travel connections). The other two meetings are typically held alongside WG5 meetings, which float around the world.  The Vegas meetings are generally in February (ok) and August (brutal!).

In the 1990s, J3 had as many as 40 members, with a mix of vendors and users (national labs, universities and user groups such as DECUS.) Due to consolidation, reduced budgets and other things, the membership of J3 is now down to 15 (eight voting members and seven alternates).  Representatives from vendors on the committee include Cray, IBM, Intel, and Sun, with user representatives from JPL, LANL, George Mason University and others. HP had been a member but lost their status due to inactivity (they can rejoin after a while).  Similarly, Fujitsu dropped out in the last year or so.  NAG's Malcolm Cohen is an alternate and does not usually attend the US meetings.  Jim Xia from IBM usually attends, but was unable to make this one.

Intel's voting member is Stan Whitlock, the Intel Fortran team lead.  He used to be DEC's and Compaq's representative "back in the days".  Lorri Menard is our first alternate and I am second alternate. I had never been to a J3 meeting and asked Stan if I might accompany him to the August session.  I wanted to meet the others, many of whom I knew only through email and newsgroup postings; the idea was that I would get a feel for how J3 did its business and perhaps help out with subcommittees.

Not a J3 member, but attending as an "observer", was Toon (pronounced "tone") Moene, a well-known gfortran developer from The Netherlands.  Toon, like some of the other non-vendor members, pays his own way to attend.  When I asked him about this, he commented that he "was single and didn't have anything better to spend [his] money on." I suggested that he needed to find a better-looking crowd to vacation with.

I was glad to meet Toon and chat with him about the unique aspects of open-source development.  He commented that finding volunteers to work on the new and interesting features of the language was relatively easy, but that the drudge work of some of the darker corners was harder to fill.

I had already flown out to the area when Stan emailed me to say that he would not be able to attend, so I was on my own!  Ulp! Thankfully, Committee chair Dan Nagle met me at the airport and introduced me to the others.  He then put me right to work!

The major business of this meeting was to respond to the dozens of comments made during the recent public comment period for the draft Fortran 2008 standard.  The comments were parceled out to subcommittees based on their topic: Data (declarations and such), HPC and interoperability, Interpretations, Edit (non-technical changes) and Journal of Requirements (JOR), which took everything else.  Toon and I joined Dan on the JOR subcommittee.

I knew that some of the comments would have broad objections to establishing a new Fortran standard "so soon", since there are not yet any complete implementations of the previous standard (IBM and Cray are probably closest.) I have a lot of sympathy for this position, but, as most of us agreed, it was much too late to do anything about it as the schedule and direction of F2008 was established years ago. F2008 could have been a "Corrections and Clarifications" revision, but there was a big push from user representatives to add major features, so that's what happened.

A secondary topic that came up yet again at this meeting, as it has for the past couple of years, regarded the addition of "co-arrays" to the language.  Co-Array Fortran (CAF) is a parallel programming addition which, unlike most others, is integrated into the language rather than a layer on top such as OpenMP or MPI.  In some ways, CAF is similar in concept to Unified Parallel C in that the programmer view is of a single program that runs as parallel images with shared access to specific variables, "co-arrays".  In CAF, co-arrays look like regular arrays with an added dimension indexed using square bracket syntax.  There are also a handful of synchronization calls.

It is true that the addition of co-arrays to the language has resulted in major edits to almost the entire language, but the editing has been done.  There are several existing implementations of CAF, notably Cray's, going back a decade.  The objections come in two flavors: one is that a "better" parallel programming paradigm (PPP!) might come along later and Fortran would be "locked in" to CAF.  This one makes no sense to me - if something better does come later, it can be adopted, but with the explosion of multi-core systems Fortran programmers need a standard and easy way of making use of parallel computation. Another objection is that some Fortran compilers have no parallel features at all, and even though one could implement CAF by recognizing the syntax but never running more than one image, users would "expect" parallel execution if they used the feature. The committee rejected both arguments and voted to keep co-arrays in the language.  This issue will come up again at the next meeting, combined with WG5 in November.

Some of the comments objected to smaller features, such as the new (in F2008) ability to pass internal procedures as actual arguments.  We've supported this for ten years, going back to DEC Fortran, but I'll admit that the implementation can be tricky.  The feature stayed in by a narrow vote margin. A couple of comments suggested that certain features were incomplete, such as the new G0 format for minimal-width output of any data type.  The comment said that this needed an additional ability to specify a number of fraction digits, otherwise one might see Pi displayed as "3".  We agreed and I ended up writing the edit to add a G0.d form.  (Hmm, writing that out reminds me of the old Fortran joke that "God is REAL - unless declared INTEGER.)

The Interop group worked on a request from the MPI Forum, which I was also involved with, to make it possible to declare a Fortran interface to a C routine that took "void *" arguments. Some compilers, including Intel's, already have such a feature, but it's typically implemented as a directive (ATTRIBUTES NO_ARG_CHECK in our case) which does fit the standard model.

After much wrangling, what we ended up with was two new features, assumed type and assumed rank.  An assumed type argument is denoted by "TYPE(*)" and matches any type or kind of an actual argument.  In generic resolution, it cannot be used to distinguish by type or kind.  An assumed rank dummy argument matches any rank of an actual, including scalar.  The syntax for this was the subject of extensive discussion: the obvious DIMENSION(*) is already taken for assumed size.  What we ended up with was "DIMENSION(..)": think of it as a colon on its side. A RANK intrinsic was also added to allow you to query the rank of the passed argument - a scalar is rank zero.

I, along with others, had argued that this feature was useful for writing Fortran routines, not just calling C. The problem is figuring out what the semantics are of accessing a variable of unknown type or rank.  What we settled on was allowing you to pass an assumed-type or assumed-rank argument to C_LOC.  You could then use C_F_POINTER to "cast" the variable to a pointer of a known type and rank.  This feature gives you a way to implement, in a standard way, the old hack of a routine that copies arbitrary data by depending on the lack of interface checking.  Note that these features are not being added to the Fortran 2008 draft itself, but rather to a "Technical Report" (TR) enhancing the C interoperability features.  TRs are the way that features get defined in a common way with a promise that they will make it into the next revision of the standard with minimal changes.  Allocatable components and function results were first done as a TR and were widely implemented before F2003 became standardized.

There's a lot more that went on at the meeting - you can read the minutes and look at the various documents. Note that some documents underwent one or more revisions, denoted by "r1", etc.

The next meeting, which is to be held alongside a WG5 meeting, will be in Tokyo in November.  This is where the 2008 draft will be locked down and I expect one last attempt to strip CAF from the language.  I will be there, representing Intel, and will be sure to let my readers know what happened.  I've never been to Japan before and am looking forward to the experience (though not the plane ride getting there.)

Sayounara!

Only slightly less known is Knuth's series of books The Art of Computer Programming (TAOCP). Planned as a seven-volume set, the first three volumes were published in the 1970s and were considered "required reading" by most everyone studying computer science. In college, I was especially taken with Knuth's use of an invented computer architecture called MIX, as it was a mixture of several well-known (at the time) architectures, and like some other college students of the era, I wrote an extended MIX interpreter, (mine was in IBM System\370 Assembler in two boxes of punch cards), that I oh-so-cleverly called XIM.

My XIM implemented not only the standard MIX instruction set, but also added all of the architectural extensions Knuth described in the volumes, such as floating point and I/O. In the mid-70s, I wrote Knuth a letter describing XIM and asking, as an aside, when we might expect to see volume 4 published. I received a thoughtful and courteous reply, saying, essentially, not to hold my breath! Sadly, my only copy of XIM perished in an apartment fire.

Knuth since has rewritten and revised TAOCP volumes 1-3 multiple times, trying to keep it relevant for the times. (Algorithms for efficient sorting of data stored on magnetic tapes are probably not as useful as they once were.) What I missed, though, was the start, in 2005, of the publication of parts of TAOCP Volume 4! Still a work in progress, Knuth has published "Fascicles", sets of chapters from the book. Fascicles 1-4 are out, and Fascicle 0 has just been released.

What? Oh, yeah. The interview. Knuth has been an advocate of what he calls Literate Programming, which if I understand it correctly, has one write programs that are designed to be read by humans so that they can understand what the program is supposed to do. I'm all in favor of this, as a long time advocate of writing understandable code and letting the compiler handle the optimization.

Knuth also expressed disdain for "unit tests", saying "lots of time is wasted on activities that I simply never need to perform or even think about. Nothing needs to be 'mocked up.'" He also takes CPU manufacturers to task for moving to multicore:

... it looks more or less like the hardware designers have run out of ideas, and that they’re trying to pass the blame for the future demise of Moore’s Law to the software writers by giving us machines that work faster only on a few key benchmarks! I won’t be surprised at all if the whole multithreading idea turns out to be a flop, worse than the [Itanium] approach that was supposed to be so terrific—until it turned out that the wished-for compilers were basically impossible to write.
...
I know that important applications for parallelism exist—rendering graphics, breaking codes, scanning images, simulating physical and biological processes, etc. But all these applications require dedicated code and special-purpose techniques, which will need to be changed substantially every few years.

Well, some at Intel would take issue with that! It is certainly true that multithreading requires a different way of approaching algorithms, and there's a lot of progress in making threading easier, but there's lots more work to do.

Knuth has also revised the 1960s-era MIX, creating MMIX, a more modern 64-bit architecture.

Finally, I note that Knuth still plans to complete the seven-volume set of TAOCP. I'll look forward to that!

I greatly admired Dick for his brilliance, his keen sense of what it meant to design things right, and for his wicked sense of humor. Dick was famous for his elaborate pranks, including the SD730 Fixed Head Solar Horologue, a sundial with a photocell that detected noon, connected by a parallel port to the VAX-11/730 which lacked a time-of-day clock. This also inspired Dick's choice of microfortnights as the unit for the VMS SYSGEN parameter TIMEPROMPTWAIT.

As a young software engineer at DEC in the late 70s and early 80s, I looked up to Dick as a shining example of what I aspired to be. Dick believed in architecture, designing and thinking things through before building, and he was great at getting cooperation and extra effort out of the VMS team. I like to think that a little of him rubbed off on me.

Tragically, Dick suffered severe brain injury in 1984 when his car was struck in an auto accident. I visited him a couple of times afterward, at the home he shared with his wife (and DEC engineer) Audrey Reith. His son Marc wrote a memorial post which provides some more information about Dick and his life.

Rest in peace, Dick. And farewell. I'm privileged to have known you.

One certainly can write clear and understandable code in Fortran, and many do. I see a lot of code from different people cross my desk each day, and I've learned to recognize certain "idioms" in Fortran code which are there to help make the code easier to understand. Meaningful variable names, use of mixed-case and free-format source, etc. Sometimes, though, a helpful coding practice can bite you. Here's one I ran across the other day...

One of the big strengths of modern Fortran is its wealth of array-oriented features. Few languages offer the whole-array and array slice operations that Fortran does, and often you can do an array operation without a traditional DO loop. For example, you can add two arrays with:

A = B + C

You can even have functions that return arrays (explicit interface required!), which freaks out some who grew up on FORTRAN 77 or even FORTRAN IV. Some programmers, though, like to remind readers that an array is an array, so they'll write code that looks like this:

A(:) = func(B(:), C(:))

with the (:) alerting the reader that the variable is an array (sort of like the Dave Barry joke that an apostrophe serves to warn you that the letter "s" is coming up in grocery store signs.) In Fortran syntax, (:) indicates an array section that starts at the first element and ends at the last element - the whole array, in other words.

Whenever I see this usage, I cringe, because I know that the compiler has to work extra hard to recognize that the programmer really meant "the whole array" and not a piece of it. In the past, unnecessary use of (:) would often prevent optimizations. Nowadays this is less often the case, thanks to hard work by the compiler developers, but sometimes it still happens. Still, most of the time, the (:) is "harmless" in that it does not change the overall meaning of the program, since an array section is "definable" (can be stored into), as long as you don't use a vector subscript such as A([1,3,5,7]).

But there's another case where the (:) can bite you.  If you are calling a procedure where the corresponding dummy argument is a deferred-shape array, then there is a difference in meaning to passing the array name A and passing A(:).  If you just pass A, then the lower bound(s) are passed along and are reflected in the dummy argument inside the called routine.  However, if you pass A(:), that's an array section and the lower bound is 1, no matter what you declared it as originally.  This will change how the array is indexed in the called procedure and can cause array bounds violation errors.

In the recent case, the customer had written something like:

A(:) = func(B)

where A was an ALLOCATABLE array and function "func" returned an array. In Fortran 90 and 95, the language required that A already be allocated and have the same shape (dimensions) as the function return value.

Fortran 2003, however, added a new twist. In F2003, if the allocatable array on the left of the assignment is not currently allocated with a shape matching the right-side, it is automatically deallocated (if needed) and then allocated with the correct shape. This can make code a lot cleaner as you don't have to worry about knowing the shape in advance.

The downside, though, is that the checking required to support this is a lot of extra code, and applications where it is known that the array is already allocated to the correct shape don't need this check which would just slow them down. This is why Intel Fortran does not support this F2003 feature by default - you have to ask for it with the option /assume:realloc_lhs, or for Linux and Mac users, -assume realloc_lhs. ("lhs" here means "left hand side".)

The programmer who wrote the above code had in fact used this feature and depended on it, with array A starting out unallocated. He was therefore surprised to find that his program, when it got to the above assignment, complained that array bounds were violated!

It turned out that it was the use of the "helpful" (:) that caused the problem. This changed the meaning of the left-hand-side from an "allocatable variable" to an array section, and as such, it did not qualify for automatic reallocation. Consider, for example, if the code had read:

A(2:5) = func(B)

you could not reallocate some elements of an array section!

The solution in this case was to remove the superfluous (:), in which case the program ran as expected. On my advice, the customer also removed unnecessary (:) in other places as they could impede optimization.

So, Doctor Fortran's advice if you put (:) on your arrays? Don't do that!

Got any other examples of Fortran coding practices that can hurt you?