https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96033
--- Comment #5 from Sylvain Korzennik <skorzennik at cfa dot harvard.edu> --- Hi Kargl, I am not interested in a protracted religious discussion, I simply do not use gfortran for my work (research), but need to provides it form my users (Smithsonian HPC cluster) as part of my duties. I've been doing HPC for 30+ years, and have used a long list of fortran compilers, all with their own extensions (SUN, VAX/VMS, CRAY, you name it) and idiosyncrasies. Most/all vendors recognize that legacy code exists, so they incorporated other's extensions and use a flexible approach to enforcing rules. GCC is the single one that decides that old code is trash and needs to be rewritten. When 64b was introduced, gfortran decided that the UNIX record integer embedded in the binary files ought to be 64b, making it impossible to use existing binary files. That's simply shooting yourself in the foot. As for a specific URL: https://www.cfa.harvard.edu/~avrett/pandora/, the PANDORA radiative transfer code is made up of 4,559 routines. It was not well designed, but it was started in 1959, with computers and compilers that had many limitations, yet I can build it w/ Intel's and PGI's F77 compilers. It needed minor one or two tweaks for runtime errors when moved from VMS to Linux. Yet by writing parameter (MSHLNG=50) integer MSHCNO,MSHLNG dimension MSHCLR(MSHLNG) data MSHCLR,MSHCNO /MSHLNG*' ', 0/ gfortran imposes a rule that did not exist -or wasn't enforced- back when: the integer declaration must be before the parameter one. The developer used VAX/VMS tools and saw no reasons to code differently (GNU did not exists). PGI and Intel do accept this order. I would have to reorder zillions of lines of code, going thru 4,000+ routines, and re-validate this complex code... unless there is a magic/hidden flag (-std=legacy isn't helping). At the end, you get what you paid for, hence we pay for PGI and Intel's compilers. I stay away from gfortran, because I have things to get done... Best, Sylvain.