Ask a working HPC programmer why numerical codes still get written in Fortran in 2026, and the answer you get is rarely about history, funding, or academic inertia. It's usually about one specific compiler behavior: pointer aliasing. This is not a piece about Fortran's culture, its supercomputer trivia, or its TIOBE ranking. It's about the one technical claim that keeps coming up in comparisons with C, whether it still holds in 2026, and what the language has actually done with that advantage in its two most recent standards. Every fact and figure below is sourced and linked, including the places where the claim turns out to be more nuanced than the confident version of it that circulates online.
The default nobody has to opt into
In Fortran, an assumed-shape array argument to a procedure is, by default, guaranteed not to overlap in memory with the other array arguments in that same procedure, unless it explicitly carries the TARGET or POINTER attribute. The compiler doesn't have to prove this. The language rules hand it that guarantee for free. That single fact is what lets a Fortran compiler safely reorder loads and stores, keep values in vector registers across iterations, and unroll and vectorize a loop without inserting a runtime check first. C makes the opposite assumption: any two pointers might refer to the same memory unless the programmer proves otherwise, so a C compiler has to generate the conservative, slower code path by default.
“It's ironic that this question arises at all, since restrict was introduced into C in order to enable optimizations that fortran compilers could already make!”
hsnyder, Fortran Discourse thread on pointers and aliasing
What C had to bolt on to catch up
C99 added the restrict keyword specifically to close this gap. Marking a pointer restrict is a promise to the compiler: nothing else in scope will read or write through a different pointer to the same memory this one touches. Make that promise honestly and the compiler can vectorize the loop the same way Fortran does by default. Break the promise, even accidentally, and the result is undefined behavior, not a warning, which is exactly why the CERT C coding standard has a dedicated rule (EXP43-C) about the ways restrict-qualified pointers can go wrong.
In practice, restrict is used sparingly outside generated code and performance-critical library internals, because getting it wrong is a correctness bug, not just a missed optimization. Fortran's assumed-shape default doesn't ask an individual programmer to make and keep that promise at every function boundary in a codebase. It's just how the array argument passing rules work, which is why the aliasing conversation in Fortran circles tends to sound less like a performance trick and more like a shrug: this was never a decision anyone had to remember to make correctly.
Whole-array syntax closes off more of the same problem
The aliasing default isn't the only place Fortran structurally avoids the bug class rather than relying on a programmer to avoid it manually. Fortran has supported whole-array expressions since Fortran 90: writing C = A + B for two same-shaped arrays A and B performs the elementwise addition directly, with no explicit index loop written by hand at all, and WHERE and FORALL constructs extend the same idea to conditional and structured assignment across an entire array in one statement. A hand-written C loop doing the equivalent work is exactly the shape of code where a subtle overlap between the input and output pointers is easiest to introduce by accident, because the loop body, the bounds, and the aliasing risk are all the programmer's responsibility at once. Fortran's array syntax doesn't just help the compiler vectorize, it removes an entire category of loop-indexing mistake from the programmer's plate in the first place, which is arguably the less-discussed half of why numerical Fortran code tends to be shorter and more directly readable as math than its C equivalent.
The honest caveat: it isn't magic
That same benchmark is worth reading precisely because it argues against overselling the aliasing story. The naive C build, unable to rule out aliasing, generated the extra instructions and ran at 2.2 GFlop/s, no faster than an equally naive Fortran build doing the same math. But hand-rewriting the C to use a thread-private accumulator, without adding restrict at all, pushed it to 11.2 GFlop/s, matching hardware bandwidth. The aliasing default explains why unoptimized Fortran doesn't fall into a specific footgun that unoptimized C can. It is not a substitute for writing memory-conscious code in either language, and it stops mattering the moment a C programmer writes (or a compiler infers) the same access pattern Fortran assumes automatically.
“the performance limiting factor should be the hardware rather than the programming language or compiler”
0xfab.ch, concluding its Fortran-vs-C aliasing benchmark
DO CONCURRENT: the parallel loop Fortran had before the buzzwords
DO CONCURRENT entered the standard in Fortran 2008 as a way to declare, in the language itself, that the iterations of a loop have no dependencies on each other and can legally run in any order, or at the same time. It doesn't require an external threading library, a pragma, or a separate parallel dialect bolted on top of the sequential language, the way OpenMP directives or CUDA kernels sit outside C and C++. It's ordinary, portable, standard-conforming Fortran, and a compiler that doesn't support parallel execution can simply run it like an ordinary DO loop with no change in meaning.
What makes it interesting in 2026 is what NVIDIA's HPC SDK does with that same construct. Compiling with the -stdpar flag, nvfortran takes DO CONCURRENT loops and offloads them directly to a GPU, moving data between host and device memory automatically under CUDA Unified Memory, with zero source-level CUDA. The change from a program's perspective can be as small as replacing the keyword do with do concurrent.
NVIDIA's HPC SDK was the first compiler to offload DO CONCURRENT to a GPU this way, and other vendors have since added their own support for GPU-targeted DO CONCURRENT, which matters more than any single vendor's number: it means this is becoming a portable way to write one parallel loop and let different compilers decide, per target machine, whether it runs across CPU cores or a GPU's thread blocks, without maintaining separate CUDA and OpenMP code paths for the same algorithm.
Fortran 2023: the standard actually moved
ISO/IEC 1539-1:2023, better known as Fortran 2023, was published on November 17, 2023, the product of roughly five years of committee work by ISO/IEC JTC1/SC22/WG5. It is not a maintenance release. Among the additions:
- A reduction specifier for DO CONCURRENT, letting the same parallel-loop construct express accumulation patterns (sums, products, min/max) that previously forced programmers back into an ordinary sequential DO loop.
- Two new enumeration-type mechanisms, including one designed for direct interoperability with C's enum types, closing a long-standing gap for code that has to call into or be called from C.
- Conditional expressions using a new ? syntax, letting a value be selected inline based on a condition without a separate IF block, aimed at code that previously relied on nonstandard compiler extensions to do the same thing.
- typeof() and classof(), new building blocks aimed squarely at generic programming, letting a declaration take on the type of another entity rather than repeating it.
- C_F_POINTER, the standard routine for turning a C pointer into a Fortran one, now accepts explicit lower bounds instead of always defaulting to 1, removing a common source of off-by-one interoperability bugs.
“An important distinction is that ? is not an operator, but part of the syntax including the enclosing parentheses.”
Steve Lionel ("Doctor Fortran"), on the Fortran 2023 conditional-expression syntax
Where the ecosystem still has real gaps
None of this means the tooling caught up instantly. LLVM's Flang, the compiler most likely to eventually give Fortran an LLVM-backed alternative to gfortran the way Clang did for C, states plainly in its own documentation that it is not yet ready for production use. It has closed most of the performance gap that mattered, reported as within roughly 10% of gfortran's geometric mean on the SPEC CPU 2017 suite while passing SPEC2017's correctness checks, but "not production-ready" from the project itself is a real caveat, not modesty. In the meantime, production HPC shops are still choosing between gfortran, Intel's ifx, NVIDIA's nvfortran, Cray's CCE, and NAG's nagfor depending on the target hardware and how strict they want compile-time checking to be, which is a wider and more fragmented compiler landscape than most languages on this site have to think about at all.
The rest of the tooling picture is younger than the language conversation suggests. fpm, the Fortran Package Manager built and maintained by the fortran-lang community, is still actively shipping releases, with version 0.13.0 landing in February 2026 adding build profiles and expanded Flang support, in a language that spent most of its existence with no standard dependency manager at all. Between a standard that gained a reduction clause and generic-programming primitives in 2023, a GPU-offload path that works by changing one keyword, and a package manager still adding features in 2026, the honest read is that Fortran's technical story right now is less "perfectly preserved" and more "actively under construction," on top of a performance default the rest of the industry is still working around.
- Fortran's assumed-shape arrays are non-aliasing by default; C achieves the same guarantee only when a programmer manually and correctly applies restrict, which is why unoptimized Fortran avoids a specific class of slow, safety-first code C compilers otherwise have to generate.
- That default is not a performance ceiling: hand-optimized C without restrict can match Fortran's throughput once the memory-access pattern itself is written well, so the real hardware ceiling still has to be earned, not assumed.
- DO CONCURRENT, standard since Fortran 2008 and extended with a reduction clause in 2023, lets a single portable loop run in parallel on a CPU or offload to a GPU, with NVIDIA's -stdpar path reporting roughly 13x on one documented Jacobi-solver benchmark.
- Fortran 2023, published November 17, 2023, added generic-programming primitives, C-interoperable enumerations, conditional expressions, and lower-bound control for C pointer interop, not just cosmetic cleanup.
- The tooling ecosystem is still catching up to the language: LLVM Flang is explicitly not production-ready yet by its own documentation, and the fpm package manager is still shipping new feature releases as of 2026.