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

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96033

--- Comment #8 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, Jul 02, 2020 at 05:31:21PM +0000, skorzennik at cfa dot harvard.edu
wrote:
> 
> I gave up on gfortran when the 64b record marker made it unusable for me. I'm
> not surprised it was fixed, but this pointed to poor decision making and
> ignoring the need to backward compatibility. When you don't need to sell your
> product, your "customers" needs might not be your highest priority.

It's a very small group of volunteers who hack on gfortran.  No
one is paid to do it (except for perhaps the OpenMP and OpenACC
extensions).  It has been a hobby for me.  I fix bugs that affect
my own codes and then address bugs reported by others as time
permits.  If Fortran were a more popular language, then things
may be different.

> Backward compatibility is a wide spread problem, in commercial products
> (trust me, some have hear mn more than once) and in 'free' ones (the
> Python 2.x vs 3.x debacle comes to mind). When you've been at it for 3
> decades, it matters.

gfortran supports a large number of extension.  I know as I either
implemented the extension (e.g., real do-loop indices and nonstandard
intrinsic subprograms) or sheparded the extension into the tree (Cray
pointers and DEC structure/union/map).  Unfortunately, extensions
make it more difficult to maintain and add the new language features
in the Fortran standards.

> PANDORA can be downloaded, and it is ugly coding (I know the author,
> he retired a while back and I was for a while helping maintain the
> code), but it may be a good example why you can't easily all a sudden
> switch to new rules, and why we maintain multiple versions of multiple
> compilers.

It isn't a matter of simply switching rules.  It's a matter of bugs
and whether the bug is reported.  In the small snippet you posted,
there is clearly a problem with implicit typing and parameter statements.
This compiles

      function jfoo()
      parameter (MSHLNG=50)
      jfoo = mshlng
      end

and this doesn't

      function ifoo()
      parameter (MSHLNG=50)
      integer   MSHLNG
      ifoo = mshlng
      end

% gfcx -c a.f
a.f:3:22:

    3 | integer   MSHLNG
      |                1
Error: PARAMETER at (1) is missing an initializer

The Fortran standard has

  If a named constant is defined by a PARAMETER statement, it shall
  not be subsequently declared to have a type or type parameter value
  that differs from the type and type parameters it would have if
  declared implicitly (8.7).

What is puzzling is that the 'parameter (mshlng=50)' is
correctly parsed.  The declaration statement is incorrectly
parsed, but I don't know why, yet.