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.
- Using Git LFS and fast-import together
- Testing in a Box: Streamlining Embedded Systems Testing
- SDV Europe: What Codethink has planned
- How do Hardware Security Modules impact the automotive sector? The final blog in a three part discussion
- How do Hardware Security Modules impact the automotive sector? Part two of a three part discussion
- How do Hardware Security Modules impact the automotive sector? Part one of a three part discussion
- Automated Kernel Testing on RISC-V Hardware
- Automated end-to-end testing for Android Automotive on Hardware
- GUADEC 2023
- Embedded Open Source Summit 2023
- RISC-V: exploring a bug in stack unwinding
- Adding RISC-V Vector Cryptography Extension support to QEMU
- Introducing Our New Open-Source Tool: Quality Assurance Daemon
- Long Term Maintainability
- FOSDEM 2023
- Think before you Pip
- BuildStream 2.0 is here, just in time for the holidays!
- A Valuable & Comprehensive Firmware Code Review by Codethink
- GNOME OS & Atomic Upgrades on the PinePhone
- Flathub-Codethink Collaboration
- Codethink proudly sponsors GUADEC 2022
- Tracking Down an Obscure Reproducibility Bug in glibc
- Web app test automation with `cdt`
- FOSDEM Testing and Automation talk
- Protecting your project from dependency access problems
- Porting GNOME OS to Microchip's PolarFire Icicle Kit
- YAML Schemas: Validating Data without Writing Code
- Deterministic Construction Service
- Codethink becomes a Microchip Design Partner
- Hamsa: Using an NVIDIA Jetson Development Kit to create a fully open-source Robot Nano Hand
- Using STPA with software-intensive systems
- Codethink achieves ISO 26262 ASIL D Tool Certification
- RISC-V: running GNOME OS on SiFive hardware for the first time
- Automated Linux kernel testing
- Native compilation on Arm servers is so much faster now
- Higher quality of FOSS: How we are helping GNOME to improve their test pipeline
- RISC-V: A Small Hardware Project
- Why aligning with open source mainline is the way to go
- Build Meetup 2021: The BuildTeam Community Event
- A new approach to software safety
- Does the "Hypocrite Commits" incident prove that Linux is unsafe?
- ABI Stability in freedesktop-sdk
- Why your organisation needs to embrace working in the open-source ecosystem
- RISC-V User space access Oops
- Tracking Players at the Edge: An Overview
- What is Remote Asset API?
- Running a devroom at FOSDEM: Safety and Open Source
- Meet the codethings: Understanding BuildGrid and BuildBox with Beth White
- Streamlining Terraform configuration with Jsonnet
- Bloodlight: Designing a Heart Rate Sensor with STM32, LEDs and Photodiode
- Making the tech industry more inclusive for women
- Bloodlight Case Design: Lessons Learned
- Safety is a system property, not a software property
- RISC-V: Codethink's first research about the open instruction set
- Meet the Codethings: Safety-critical systems and the benefits of STPA with Shaun Mooney
- Why Project Managers are essential in an effective software consultancy
- FOSDEM 2021: Devroom for Safety and Open Source
- Meet the Codethings: Ben Dooks talks about Linux kernel and RISC-V
- Here we go 2021: 4 open source events for software engineers and project leaders
- Xmas Greetings from Codethink
- Call for Papers: FOSDEM 2021 Dev Room Safety and Open Source Software
- Building the abseil-hello Bazel project for a different architecture using a dynamically generated toolchain
- Advent of Code: programming puzzle challenges
- Full archive