https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96033
--- Comment #6 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- On Thu, Jul 02, 2020 at 04:10:38PM +0000, skorzennik at cfa dot harvard.edu wrote: > > 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. > That problem was recognized and fixed long ago. See the -frecord-marker and -fmax-subrecord-length options. > As for a specific URL: https://www.cfa.harvard.edu/~avrett/pandora/, the > PANDORA radiative transfer code is made up of 4,559 routines. Thanks for the URL. If the code is freely downloadable, I'll grab it and check out what gfortran does. > 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. > There can be bugs in the compiler. Unreported bugs tend to go unfixed. Ufortunately, there are more bugs than volunteers to fix them.
