[Bug fortran/96033] error: The Fortran compiler gfortran will not compile files that call the same routine with arguments of different types.

skorzennik at cfa dot harvard.edu gcc-bugzilla@gcc.gnu.org
Thu Jul 2 16:10:38 GMT 2020


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.


More information about the Gcc-bugs mailing list