[Bug fortran/104812] New: Construct-name with same variable name in scope

[Bug fortran/104812] New: Construct-name with same variable name in scope

[fruitclover at gmail dot com]

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

            Bug ID: 104812
           Summary: Construct-name with same variable name in scope
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: fruitclover at gmail dot com
  Target Milestone: ---

Is this expected behavior for s1 to disallow construct-name with the same name
as declared variable? 

$ cat -n test.f90
     1  subroutine s1
     2    logical :: x
     3    x: if (x) then
     4    end if x
     5  end
     6  
     7  subroutine s2
     8    logical :: x
     9    x: block
    10    end block x
    11  end

$ gfortran test.f90 -fsyntax-only -Wall -Wextra
test.f90:3:11:

    3 |   x: if (x) then
      |           1
Error: Symbol at (1) is not appropriate for an expression
test.f90:4:5:

    4 |   end if x
      |     1
Error: Expecting END SUBROUTINE statement at (1)

[Bug fortran/104812] Construct-name with same variable name in scope

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from kargl at gcc dot gnu.org ---
gfortran is correct.  See Fortran 2018, 19.4, p 498.

   Identifiers of entities, other than statement or construct entities (19.4),
   in the classes

     (1) named variables, ..., named constructs, ...,


  Within its scope, a local identifier of one class shall not be the
  same as another local identifier of the same class,

[Bug fortran/104812] Construct-name with same variable name in scope

[fruitclover at gmail dot com]

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

--- Comment #2 from Mike K. <fruitclover at gmail dot com> ---
Thanks, and subroutine s2 conforming Fortran 2018, 19.4, right?

[Bug fortran/104812] Construct-name with same variable name in scope

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, Mar 10, 2022 at 11:27:41AM +0000, fruitclover at gmail dot com wrote:
> 
> --- Comment #2 from Mike K. <fruitclover at gmail dot com> ---
> Thanks, and subroutine s2 conforming Fortran 2018, 19.4, right?
> 

No. The logical variable 'x' is a local entity.  You
have 'x:i block' where this 'x' is a construct name
and conflicts with the local variable.

Note, the prohibition in the standard is not a numbered
constraint, which means a compiler need not issue an
error or warning.  It is expected that the programmer
writes conforming code.

If you actually try to use the variable 'x', you'll get 
an error.

subroutine s2
  logical :: x
  x: block
    x = .true.
  end block x
  if (x) print *,'whoops'
end

% gfcx -c a.f90 
a.f90:4:6:

    4 |     x = .true.
      |      1
Error: 'x' at (1) is not a variable
a.f90:6:8:

    6 |   if (x) print *,'whoops'
      |        1
Error: Symbol at (1) is not appropriate for an expression'

[Bug fortran/104812] Construct-name with same variable name in scope

[fruitclover at gmail dot com]

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

--- Comment #4 from Mike K. <fruitclover at gmail dot com> ---
Created attachment 52749
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52749&action=edit
propose to return an error if constuct-name clashes with variable name

> Note, the prohibition in the standard is not a numbered
> constraint, which means a compiler need not issue an
> error or warning.  It is expected that the programmer
> writes conforming code.

Could we enforce this constraint and print error message instead of relying on
programmer? I think that explicit error is better than silently accepting
non-conforming code for some corner-cases.

Attached patch with proposed fix, wdyth?

[Bug fortran/104812] Construct-name with same variable name in scope

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |---
     Ever confirmed|0                           |1
           Priority|P3                          |P4
             Status|RESOLVED                    |REOPENED
   Last reconfirmed|                            |2022-04-05

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to Mike K. from comment #4)
> Created attachment 52749 [details]
> propose to return an error if constuct-name clashes with variable name
> 
> > Note, the prohibition in the standard is not a numbered
> > constraint, which means a compiler need not issue an
> > error or warning.  It is expected that the programmer
> > writes conforming code.
> 
> Could we enforce this constraint and print error message instead of relying
> on programmer? I think that explicit error is better than silently accepting
> non-conforming code for some corner-cases.
> 
> Attached patch with proposed fix, wdyth?

Thanks for the patch.  I no longer commit due to the migration to git.

I've changed the Status to Reopened so that another gfortran developer
might take a look.

You can likely get some attention for this PR and your patch if
you post it in fortran@gcc.gnu.org and gcc-patches@gcc.gnu.org.
Ask someone to committed.  You might need to ping the email after
a week or so if no one respondes.

[Bug fortran/104812] Construct-name with same variable name in scope

[fruitclover at gmail dot com]

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

--- Comment #6 from Mike K. <fruitclover at gmail dot com> ---
Thanks a lot for the guidance, posted patch.