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

[fruitclover at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Mike K.  ---
Thanks a lot for the guidance, posted patch.

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

[fruitclover at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Mike K.  ---
Created attachment 52749
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52749=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

[fruitclover at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Mike K.  ---
Thanks, and subroutine s2 conforming Fortran 2018, 19.4, right?

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

[fruitclover at gmail dot com via Gcc-bugs]

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
 2logical :: x
 3x: if (x) then
 4end if x
 5  end
 6  
 7  subroutine s2
 8logical :: x
 9x: block
10end 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 c++/89616] Parameter names can be redeclared in outermost block of a function definition

[fruitclover at gmail dot com]

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

Michael Kashkarov  changed:

   What|Removed |Added

 CC||fruitclover at gmail dot com

--- Comment #1 from Michael Kashkarov  ---
Created attachment 45954
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45954=edit
patch

Possible fix is attached (bootstraps x86_64), detects the following case:

 1 void foo(int x){
*2void x();
 3 }

but not sure if the following redefinition is legal (compiles with gcc/clang):

 1 class C {
 2   int x;
 3 public:
 4   C(int);
 5 };
 6 
 7 C::C(int x) try : x(1) {
*8 void x();
 9 } catch (...) {}

from [basic.scope.param]:
... A parameter name shall not be redeclared in the outermost block of the
function definition nor in the outermost block of any handler associated with a
function-try-block.