Hi Mark, OK for master. If you want to backport, that's fine by me but please give it a few weeks.
Thanks for fixing this. Paul On Tue, 13 Oct 2020 at 08:17, Mark Eggleston <mark.eggles...@codethink.co.uk> wrote: > **ping** > > previously omitted commit message added > > On 29/09/2020 14:03, Mark Eggleston wrote: > > For review. > > > > When the first attempt was committed the result was PR97224 i.e. it > > broke the build of SPECCPU 2006 Games. > > > > I've changed the condition under which the error is produced. It was > > produced in the local symbol was also found as a global symbol and the > > the type of the symbol was not GSYM_UNKNOWN and not GSYM_COMMON. This > > meant that subroutine names in commons in the SPECCPU source code were > > rejected. > > > > The condition no produces an error if the global symbol is either > > GSYM_MODULE or GSYM_PROGRAM. > > > > The relevant section in the standard (19.3.1 (2)): > > > > "Within its scope, a local identifier of an entity of class (1) or > > class (4) shall not be the same as a global identifier used in that > > scope unless the global identifier > > > > * is used only as the use-name of a rename in a USE statement, > > * is a common block name (19.3.2), > > * is an external procedure name that is also a generic name, or > > * is an external function name and the inclusive scope is its defining > > subprogram (19.3.3)." > > > > I've added two new test cases for subroutine and function. > > > > I'm not certain about the restriction that the external procedure > > should be a generic name. I have found the earlier standards somewhat > > confusing on the subject, so I haven't determined whether there should > > be any standards dependent code. > > > [PATCH] Fortran : ICE in build_field PR95614 > > Local identifiers can not be the same as a module name. Original > patch by Steve Kargl resulted in name clashes between common block > names and local identifiers. A local identifier can be the same as > a global identier if that identifier is not a module or a program. > The original patch was modified to reject global identifiers that > represent a module or a program. > > 2020-09-29 Steven G. Kargl <ka...@gcc.gnu.org> > Mark Eggleston <markeggles...@gcc.gnu.org> > > gcc/fortran/ > > PR fortran/95614 > * decl.c (gfc_get_common): Use gfc_match_common_name instead > of match_common_name. > * decl.c (gfc_bind_idents): Use gfc_match_common_name instead > of match_common_name. > * match.c : Rename match_common_name to gfc_match_common_name. > * match.c (gfc_match_common): Use gfc_match_common_name instead > of match_common_name. > * match.h : Rename match_common_name to gfc_match_common_name. > * resolve.c (resolve_common_vars): Check each symbol in a > common block has a global symbol. If there is a global symbol > issue an error if the symbol type is a module or a program. > > 2020-09-29 Mark Eggleston <markeggles...@gcc.gnu.org> > > gcc/testsuite/ > > PR fortran/95614 > * gfortran.dg/pr95614_1.f90: New test. > * gfortran.dg/pr95614_2.f90: New test. > * gfortran.dg/pr95614_3.f90: New test. > * gfortran.dg/pr95614_4.f90: New test. > > -- > https://www.codethink.co.uk/privacy.html > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
