Why would we be talking about FORTRAN 77 in 2023?

Because there are still codebases in active use and development in FORTRAN 77.

That was my first thought as well. I’ve had researchers running an in-house built Fortran program in the field of genetics on our HPC clusters, such that they’d run their task as 1000s of jobs in the cluster each operating on a small segment of data instead of a single program making use of as many cores available in the system. Perhaps, newer Fortran would’ve done it, but the old software was still reliant on old Fortran.

New and old Fortran is incredibly compatible. Chances are you can rewrite or refactor to add new features directly into or along the old code. If you know what you’re doing.

Fortran 90+ has strong support for parallel programming, including MPI, OpenMP, CUDA and OpenAPI (for GPU).

things have advanced a little since then - speaking as someone that really liked f77 :-) but even way back when i think there were parallel options, if your hardware could support them.

Makes sense, somehow I assumed things stayed the same. Turns out I only know fortran from the memes about it.

The important thing is that old programs and libraries keep working.

Some features were removed from the standard, and modern compilers are much better at detecting errors (and are much stricter than they used to be by default), but all of them have a switch to make them work with random codes from the 1980s.

There is an awful lot of new features on top of that (things like first-class multidimensional arrays language-level parallelism, object orientation, modules, etc), but old software keeps working.

This is an allusion to coarrays, which is a feature from Fortran 2008. It is actually very neat and very nice to program for. There is a C thing that took inspiration from it: https://en.m.wikipedia.org/wiki/Unified_Parallel_C .

Do concurrent loops can also be parallelized.

Yes, a lot of things can be parallelised with OpenMP or MPI, just like in C/C++. These extensions and libraries are not core language features, though.

Very true, and it opens the door to new optimizations which are not possible when going through a library (at least in the case of MPI).

DO CONCURRENT is not a parallel construct. It is a serial loop with arbitrary ordering of iterations, and limitations on data accesses that were intended to ease parallelization but turned out to be incorrect.

I agree that it is not a parallel construct. But it can nonetheless be parallelized if certain criteria are met.

Unfortunately, the necessary restrictions on data accesses to enable parallel execution are not required to hold true in the body of a DO CONCURRENT loop by its botched specification, and neither can they be verified at compilation time. And the committee has known about these problems for many years and has refused to fix them; Fortran 2023 still has them and the topic is not going to be brought up again for Fortran 2028.

So it is possible for a conforming program to be non-parallelizable, due to holes in the default data localization rules, despite the name of the construct and the obvious intent of the long list of restrictions imposed on code in the construct.

I summarized the two specific problems in https://github.com/llvm/llvm-project/blob/main/flang/docs/Do....

It's an excellent essay, and the Fortran community owes you a major gratitude for promoting these issues. But surely there loops can be safely parallelized if the iterations do not interact, e.g. per-element array arithmetic, and a compiler ought to safely identify such arithmetic.

Also, isn't your employer promoting do concurrent as a method of GPU parallelization? Has this been controversial within Nvidia?