[PATCH] Fortran : ICE in build_field PR95614 (2nd attempt)

Mark Eggleston mark.eggleston@codethink.co.uk
Tue Oct 13 07:16:57 GMT 2020


**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  <kargl@gcc.gnu.org>
         Mark Eggleston  <markeggleston@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 <markeggleston@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



More information about the Fortran mailing list