[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc-bugs
Subject:    [Bug fortran/85575] New: Acceptance of invalid code: ordering of declaration statements with implici
From:       "juergen.reuter at desy dot de" <gcc-bugzilla () gcc ! gnu ! org>
Date:       2018-04-30 13:26:14
Message-ID: bug-85575-4 () http ! gcc ! gnu ! org/bugzilla/
[Download RAW message or body]

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

            Bug ID: 85575
           Summary: Acceptance of invalid code: ordering of declaration
                    statements with implicit typing
           Product: gcc
           Version: 8.0.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

I think I saw discussions on this topic already on c.l.f. I am having the
following subroutine (and the recursive attribute doesn't play a role)
1 recursive function constr_quark_loopline(ho,sho) result(cl)
2   integer, dimension(sho), intent(in) :: ho
3   integer, dimension(sho)             :: hor
4   integer, intent(in)                 :: sho
5   [...]
6 end function constr_quark_loopline

Intel gives an error message error #6415: This name cannot be assigned this
data type because it conflicts with prior uses of the name.   [SHO]

in the case this is an external procedure, or a module procedure with or
without 'implicit none' in the head of the module.

First of all, I would like to get it confirmed that this is really a
contradiction of the standard, and that the order of the declarations matters.
In case this is a module procedure without implicit none or an external
procedure, implicit typing rules apply and sho would be considered to be a
real, such that later specifying it as an integer is a contradiction. gfortran
and nagfor complain:

   integer, intent(in)                 :: sho  
                                            1
Error: Symbol ‘sho' at (1) already has basic type of REAL

and

Error: rec.f90, line 8: Symbol SHO has already been implicitly typed
       detected at SHO@<end-of-statement>

The strange thing (which seems a compiler bug to me) is that gfortran compiles
this code when it is a module procedure with 'implicit none'. This seems a 
(gfortran) compiler bug to me to accept this code. I see this behavior with all
gfortran versions that I can get a hold on, 4.8, 4.9., 5.4, 6.3, 7.3, 8.0 and
9.0. That is the reason I filed this report. Comments are appreciated.

And yes, of course, I know that having the declaration of sho first solves all
the problems, but this is 3rd-party code.=
[prev in list] [next in list] [prev in thread] [next in thread]