The key advantage of fortran is that it doesn't allow pointer aliasing, which allows the compiler to vectorize more. Couple that with the typical fortran use cases and compiler vendors competing on performance by vectorizing more and more.
What you end up with is a language with a reputation for being faster for computation
When C99 introduced the restrict keyword this argument fell apart.
But I can assure you, the vast majority of legacy Fortran is not vectorizable. At least not without a bit of refactoring.
Oh and did I mention, most of this legacy code was hand optimized for memory utilization. You see, back in the day 8k of memory was cutting edge HPC and about half that went to the OS and compiler. Well we all know, everything is a balancing act between time and space - the old timers traded time for space just to be able to do the computation at all on the hardware they had.
> When C99 introduced the restrict keyword this argument fell apart.
1) Nobody puts "restrict" everywhere, and in C it can be very dangerous to do so unless you're exceedingly careful.
2) The fact that few codebases use it means it's riddled with compiler bugs even if you are exceedingly careful. Just look at how many times Rust has had to disable noalias due to LLVM bugs and regressions.
Just because Fortran does the equivalent of implicitly using restrict everywhere does not mean the compiler actually statically checks for abuse. You can just as easily write bad pointer aliasing code in Fortran and depending on what optimization level you built with you may or may not experience memory corruption and/or segmentation fault at run time.
AIUI, the only language in common use that has comprehensive static checks for their equivalent to 'restrict' is Rust. Not coincidentally, there's quite a bit of interest in Rust adoption for numerics-heavy and scientific codes, the traditional preserve of FORTRAN.
You seem to be operating under the assumption that the Fortran compiler will catch pointer aliasing. In fact major implementations of Fortran do not (for technical reasons).
So the standard just says "don't do it, LOL" but then you are able to write Fortran violating this. Which is how you end up with bugs that go away when you switch optimization levels.
You seem to be operating under the assumption that the C developers know how to use restrict, when in practice they don't, so it hasn't made the argument fell apart.
In fact, only C++ is able to confortably beat Fortran, despite not having official support for restrict, because of the stronger type system and compile type metaprogramming that offer optimization opportunities out of reach to C compilers.
Usually HPC places like CERN and Fermilab don't migrate their aginging Fortran code to C, rather C++.
What you end up with is a language with a reputation for being faster for computation