[Bug fortran/113165] New: Code containing more than one type declaration for a variable results in confusing error messages from compiler

[Bug fortran/113165] New: Code containing more than one type declaration for a variable results in confusing error messages from compiler

[xecej4 at outlook dot com]

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

            Bug ID: 113165
           Summary: Code containing more than one type declaration for a
                    variable results in confusing error messages from
                    compiler
           Product: gcc
           Version: 11.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: xecej4 at outlook dot com
  Target Milestone: ---

Created attachment 56960
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56960&action=edit
Fixed form Fortran77 source file that causes compiler to issue confusing
messages

Some old Fortran codes (e.g., www.netlib.org/ode/epsode.f ) may contain
duplicate declarations of some variables. Lines 1239-1241 of epsode.f:

      double precision eps, epsj, h, hmax, hmin, pw, save1, save2,
     1                 ss, t, uround, ymax
      double precision d, r, r0, t, yj

The variable t is declared twice, albeit with the same type and kind.

Gfortran correctly flags this error, but seems to go farther and mark the
variable t as implicitly typed single precision REAL, causing the issuing a
number of misleading error messages when the concerned variable is used in
expressions later on in the program unit.

I enclose a short program to illustrate. Please compile the program with (a) no
options, (b) with -Wall and (c) with -fimplicit-none. Case (c) results in:

muldecl.f:4:24:

    4 |       double precision d,q,r  ! 'd' was already declared as double
prec.
      |                        1
Error: Symbol 'd' at (1) already has basic type of REAL
muldecl.f:7:7:

    7 |       r = sqrt(d)
      |       1
Error: Symbol 'r' at (1) has no IMPLICIT type

I suspect that the multiple declaration of d has caused even the unrepeated
declaration of r to be tainted.

[Bug fortran/113165] Code containing more than one type declaration for a variable results in confusing error messages from compiler

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P5
                 CC|                            |kargl at gcc dot gnu.org
           Severity|normal                      |enhancement

--- Comment #1 from kargl at gcc dot gnu.org ---
You are hitting a run-on error caused by the first reported error.
If you are compiling old code or code you are currently writing or
code with a questionable pedigree, use the -fmax-errors=1 option.

For the record, your bug report is confusing ;-)
Because it includes error messages associated with your attached example:

      program multDecls
      double precision a,b,c,d,f,g
      integer i,j,k,l
      double precision d,q,r  ! 'd' was already declared as double prec.
      d = 65536.0d0
      r = sqrt(d)
      print *,' r = ',r,' p = ',p
      end program

but you refer to netlib code with a duplicate 't' declaration.

Due to the first error about 'd', the rest of the declaration is 
discarded.  The result is that 'q,r' have not been declared
and so have implicit types.  The option '-fimplicit-none' is telling
you about this problem.  Fix the first error and the run-on errors
go away.

Note, "Error: Symbol 'd' at (1) already has basic type of REAL" simply
means that 'd' has been typed as a REAL entity irrespective of the kind.
It does not mean that 'd' has been given a single precision type of 
REAL(4).  I suppose someone could change the error message to
a more generic "Error: Symbol 'd' at (1) has already been declared."
or some such wording.

[Bug fortran/113165] Code containing more than one type declaration for a variable results in confusing error messages from compiler

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
With the attached example code and the patch at the end of this
message, gfortran can be changes to identify both lines of code.
Fixing the run-on errors when -fimplicit-none is used is left as
an exercise for a new contributor or will be ignored until such
time as someone closes this bug report.

% gfcx -c e.f90
e.f90:3:30:

    3 |       double precision a,b,c,d,f,g
      |                              1
    4 |       integer i,j,k,l
    5 |       double precision d,q,r  ! 'd' was already declared as double
prec.
      |                        2      
Error: Symbol ‘d’ declared at (1) already has basic type of REAL and cannot
appear in the declaration at (2)



diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
index a6078bc608a..7fa1839323b 100644
--- a/gcc/fortran/symbol.cc
+++ b/gcc/fortran/symbol.cc
@@ -2015,8 +2015,9 @@ gfc_add_type (gfc_symbol *sym, gfc_typespec *ts, locus
*where)
        gfc_error ("Symbol %qs at %L already has basic type of %s",
                   sym->ns->proc_name->name, where, gfc_basic_typename (type));
       else
-       gfc_error ("Symbol %qs at %L already has basic type of %s", sym->name,
-                  where, gfc_basic_typename (type));
+       gfc_error ("Symbol %qs declared at %L already has basic type of %s "
+                  "and cannot appear in the declaration at %L", sym->name,
+                  &sym->declared_at, gfc_basic_typename (type), where);
       return false;
     }

[Bug fortran/113165] Code containing more than one type declaration for a variable results in confusing error messages from compiler

[xecej4 at outlook dot com]

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

--- Comment #3 from mecej4 <xecej4 at outlook dot com> ---
Thanks for the prompt response and the rapid fix.