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

[Bug fortran/96033] New: 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]

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

            Bug ID: 96033
           Summary: error: The Fortran compiler gfortran will not compile
                    files that call the same routine with arguments of
                    different types.
           Product: gcc
           Version: 10.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: skorzennik at cfa dot harvard.edu
  Target Milestone: ---

Failed to configure to build mvapich2-2.3.[14] (both versions) using GCC
10.1.0. I have no problem building mvapich2 w/ GCC pre-10.x (9.3, 9.2, etc...)

Boils down to trying to compile
conftest.f
::::::::::::::
      program main
      integer a
      real b
      character c
      call foo1(a)
      call foo1(b)
      call foo1(c)
      end

This test code compiles fine w/ 9.3.0, or older GCC I have installed and tried
(9.2.0, 7.3.0 or 4.8.5).

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
This is the intended behavior. Compile the faulty code with
-std=legacy

[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]

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

--- Comment #2 from Sylvain Korzennik <skorzennik at cfa dot harvard.edu> ---
Merci Dominique. 

Will transmit info to MVAPICH2 ppl. 

The configuration script needs to be changed, this is not "faulty code", it is
a test code part of the package configuration specifically to test if the
"Fortran compiler gfortran will compile files that call the same routine with
arguments of different types".

I ran the configurator ok by setting env vars FFLAGS and FCFLAGS to -std=legacy
- hopefully it will build fine.

These kind of changes make GCC harder and harder to use/maintain in a
professional setting, IM(H)O. 

Backward compatibility of gfortran is dismal (legacy code that builds fine w/
plethora of other fortran compiler fails to build w/ gfortran - ppl were
writing fortran code for quite a wile, like one big scientific package started
60+ years ago, yet gfortran is the one that can't handle it - ifort and
pgfortran do fine, it was written/developed on a VAX/VMS back when - author
have long retired - desn't make the code obsolete, tho).

A bien entendeur.

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

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
You can find a quite long discussion about legacy at

https://groups.google.com/forum/#!topic/comp.lang.fortran/Ed8Mccy9zo8

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

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Sylvain Korzennik from comment #2)
> Merci Dominique. 
> 
> Will transmit info to MVAPICH2 ppl. 
> 
> The configuration script needs to be changed, this is not "faulty code", it
> is a test code part of the package configuration specifically to test if the
> "Fortran compiler gfortran will compile files that call the same routine
> with arguments of different types".

It is faulty code according to the Fortran standard.  It's been faulty code
since it was written.

  Fortran 66

  8.3.2 Referencing External Functions.

  An external function is referenced by using its reference (5.2) as
  a primary in an arithmetic or logical expression.  The actual arguments,
  which constitute the argument list, must agree in order, number, and
  type with the corresponding dummy argumets in the defining program
  unit.

  8.4.2 Referencing Subroutines.

  A subroutine is referenced by a CALL statement (7.1.2.4).  The actual
  arguments, which constitute the argument list, must agree in order,
  number, and type with the corresponding dummy arguments in the defining
  subprogram.

Modern Fortran allows a programmer to write a generic interfaces, which
allows one to handle this situation in a standard conforming way.

> Backward compatibility of gfortran is dismal (legacy code that builds fine
> w/ plethora of other fortran compiler fails to build w/ gfortran - ppl were
> writing fortran code for quite a wile, like one big scientific package
> started 60+ years ago, yet gfortran is the one that can't handle it - ifort
> and pgfortran do fine, it was written/developed on a VAX/VMS back when -
> author have long retired - desn't make the code obsolete, tho).

URLs to the actual code, please.  All that unnamed legacy code violates
the Fortran standard in one or more ways.  gfortran, unlikely the plethora
of compilers, is not a garbage disposal.

[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]

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.

[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 #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.

[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]

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

--- Comment #7 from Sylvain Korzennik <skorzennik at cfa dot harvard.edu> ---
Thanks for following up, Steve.

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.

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.

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.

Have a great 4th of July, stay sane, safe and healthy, 6+ft away!
 Cheers,
      Sylvain

[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.

[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 #9 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, Jul 02, 2020 at 06:30:40PM +0000, sgk at troutmask dot
apl.washington.edu wrote:
> 
> 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.
> 

When bugs are reported, they sometime get fixed.

(Copy-n-paste tab corruption in patch)

Index: gcc/fortran/decl.c
===================================================================
--- gcc/fortran/decl.c (revision 280157)
+++ gcc/fortran/decl.c (working copy)
@@ -1864,13 +1864,16 @@ add_init_expr_to_sym (const char *name, gfc_expr **ini

   /* If this symbol is confirming an implicit parameter type,
      then an initialization expression is not allowed.  */
-  if (attr.flavor == FL_PARAMETER
-      && sym->value != NULL
-      && *initp != NULL)
+  if (attr.flavor == FL_PARAMETER && sym->value != NULL)
     {
-      gfc_error ("Initializer not allowed for PARAMETER %qs at %C",
-   sym->name);
-      return false;
+      if (*initp != NULL)
+ {
+   gfc_error ("Initializer not allowed for PARAMETER %qs at %C",
+       sym->name);
+   return false;
+ }
+      else
+ return true;
     }

   if (init == NULL)