Passing the age of retirement: our work with Fortran and its compilers

Fortran will be turning 65 this November and, though the programming language may conjure up images of punch cards and room-sized computers, it is certainly not dead. Originally developed by IBM in the early 1950s for scientists and engineers (hence its name, FORmula TRANslation), it found early success with the target audience. For the last six decades it has remained a popular choice in scientific circles, and has since been subject to several revisions, updating and modernising the language’s feature-set. The latest revision, Fortran 2018, is only a little over a year old.

Though it may seem ancient, Fortran is still being used today. Along with updates to the language, updates to the various compilers that turn the human-readable code into machine code have taken place over the last half-century. The most popular ones today are Intel’s compiler (ifort), IBM’s XL compiler, and the GNU Compiler Collection’s compiler (GFortran). Each is preferred for different purposes and applications: the consensus seems to be that the former two are best at creating the most efficient and optimised executables, whilst GFortran is the most useful for debugging.

Unlike IBM’s and Intel’s offerings, the GNU Project’s Fortran compiler is Free and Open Source Software (FOSS). It is the most popular FOSS compiler for the language available today and features full support for Fortran 90 and 95, and partial support for prior and subsequent revisions of the language. This wasn’t always the case; even as recently as 3 years ago, support for pre-F90 Fortran was almost non-existent. Though it remains spotty, it has seen some noticeable improvement since.

Though GFortran may not be as popular as the proprietary offerings in production environments, this does not mean it is not a choice worth considering, or that it might not even be a better choice than those produced by larger companies. This may have something to do with the codebases that said companies have; when it comes to millions of lines of code, some of which are legacy code or non-standard code, using open-source software becomes less of a luxury and more of a practicality. Thanks to the availability of the source code, a group of developers can dig into the code and modify it to meet their own ends. This was the case with one of our clients, whose current working version of GFortran includes more than a dozen significant patches to allow it to compile the specific versions and combinations of Fortran that they use.

On our side, we maintain these patches, and make sure that as the compiler gets updates, it can still compile the client’s code. That is not, however, all that we do -- we also try to upstream said patches.

Upstreaming changes to open-source programs is not just good samaritanism (though it is something that should be encouraged for this reason alone). Sending code back to a project’s core developers means integrating it with the rest of the project, which for the companies that develop this software, means not having to take care of its maintenance themselves. This is less time and money being spent for companies for the same result -- or an even better one.

Better how? Well, that’s the double-edged sword of upstreaming. The code created by upstream developers is often held to a very high standard, so everyone downstream gets to play around with well-crafted, high-performing software. On the other hand, upstreaming code is notoriously difficult on a number of projects. GFortran is no exception.

Mark Eggleston, one of Codethink’s Fortran experts, explained that “sometimes you need to jump through a lot of hoops.” Getting a patch ready for submission upstream is hard enough when it comes to a project like this; but sending it off to the developers’ mailing list is a little daunting.

The patch is sent upstream with an explanation for the addition of this code, and then one waits for it to be reviewed. In theory, if the patch is good enough, it is simply accepted and is then committed by a member of the developer team with the power to do so. In practice, this almost never happens; more often than not, the core developer team returns to the submitter with proposed improvements. This means going back and changing the patch to address the constructive (and often extensive!) feedback of the upstream team, and ensuring the quality of the code is up to their standards.

For newcomers, one of the hardest parts of working on the compiler is actually understanding how it works. “Docs are… limited, to say the least,” says Eggleston: “[you] need to get your hands dirty.” Only as a result of tinkering, digging through the code, and playing around with the results, can one expect to understand how parts of the compiler were designed and how they fit together.

This makes GFortran sound like a pain to work with, but in truth, these issues are symptoms of bigger benefits. Tough and exhausting quality control upstream ensures that GFortran is a compiler that users beyond enthusiasts will want to use, sometimes over the solutions provided by competitors like Intel. Additionally, though poor documentation can make development painful, it is a far easier issue to deal with than not having any access to the compiler’s source code at all, which is the case for the proprietary alternatives. It is not surprising, then, that Red Hat pushes this compiler as their tool of choice.

Thankfully, thanks to the community, these issues are further diminished. GFortran’s developers are quick to give advice, give their thoughts, and guide users in the right direction. The fact that they are working out of a passion for the project shows in the warmth with which they treat those who are new to it, or are looking for solutions to their problems.

Though Mark is a relative newcomer to GFortran -- he’s been working on it for a little over a year -- he has now been granted commit privileges on the project’s main repository thanks to his efforts. “I suppose being accepted into a project’s commit group after 1 year isn’t bad!” If one year seems like an awfully short time to get to grips with a project like a Fortran compiler, that’s because his first work with the language was actually decades ago. Despite the transition from FORTRAN IV, which he used when he finished his degree in 1986, to FORTRAN 90 being a bit of a shock, he seems happy to be working with the language over thirty years later.

At this rate, Fortran will last into the 22nd century anyway.