[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
Thu Jul 2 18:30:40 GMT 2020
--- 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
> 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
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.
jfoo = mshlng
and this doesn't
ifoo = mshlng
% gfcx -c a.f
3 | integer MSHLNG
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.
More information about the Gcc-bugs