Re: [PATCH] Fortran : ICE in build_field PR95614 (2nd attempt)
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 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 > Mark Eggleston > > 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 > > 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
Re: [PATCH] Fortran : ICE in build_field PR95614 (2nd attempt)
**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 Mark Eggleston 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 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
Re: *PING* Re: [PATCH] Fortran : ICE in build_field PR95614
Hi Mark, I haven't yet committed this. I am unfamiliar with Andre, I've checked MAINTAINERS and I find Andre in the "Write after approval" section. Is Andre's approval sufficient? If so MAINTAINERS needs to be updated. The official list of people who can review is at https://gcc.gnu.org/fortran/ but that is clearly not sufficient. We need to update it to reflect current realities, there are people who have approved patches (with nobody objecting) for a long time, and many people who are on that list are no longer active. I'm not 100% sure what is needed to update that file, if we need OK from the steering committee or not. I had already taken a straw poll I think I will simply do tomorrow moring. If anybody strenuously objects, we can always revert the patch :-) If not: OK to commit and backport? OK from my side, and thanks for the patch. Best regards Thomas
*PING* Re: [PATCH] Fortran : ICE in build_field PR95614
I haven't yet committed this. I am unfamiliar with Andre, I've checked MAINTAINERS and I find Andre in the "Write after approval" section. Is Andre's approval sufficient? If so MAINTAINERS needs to be updated. If not: OK to commit and backport? regards, Mark On 14/09/2020 09:03, Andre Vehreschild wrote: Hi Marc, the patch looks reasonable and ok to me. Ok for trunk. Thanks for the patch. Regards, Andre On Fri, 4 Sep 2020 08:35:59 +0100 Mark Eggleston wrote: Please find attached a fix for PR95614. The original patch was by Steve Kargl. The original patch resulted in name clashes between global identifiers naming common blocks and local identifiers. According to the 2018 standard 19.3.1 Classes of local identifiers, item 2, a local identifier shall not be the same as a global identifier, however, there is an exception where the global identifier is a common block name. The change to the patch is: if (gsym && gsym->type != GSYM_UNKNOWN && gsym->type != GSYM_COMMON) instead of: if (gsym && gsym->type != GSYM_UNKNOWN) Tested on x86_64 using make -j 8 check-fortran. OK to commit? [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 represents a common. The patch was modified to allow global identifiers that represent a common block. 2020-09-04 Steven G. Kargl Mark Eggleston 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 known as is not a common block name. 2020-09-04 Mark Eggleston gcc/testsuite/ PR fortran/95614 * gfortran.dg/pr95614_1.f90: New test. * gfortran.dg/pr95614_2.f90: New test. -- https://www.codethink.co.uk/privacy.html
Re: [PATCH] Fortran : ICE in build_field PR95614
Hi Marc, the patch looks reasonable and ok to me. Ok for trunk. Thanks for the patch. Regards, Andre On Fri, 4 Sep 2020 08:35:59 +0100 Mark Eggleston wrote: > Please find attached a fix for PR95614. The original patch was by Steve > Kargl. > > The original patch resulted in name clashes between global identifiers > naming common blocks and local identifiers. According to the 2018 > standard 19.3.1 Classes of local identifiers, item 2, a local identifier > shall not be the same as a global identifier, however, there is an > exception where the global identifier is a common block name. > > The change to the patch is: > > if (gsym && gsym->type != GSYM_UNKNOWN && gsym->type != GSYM_COMMON) > > instead of: > > if (gsym && gsym->type != GSYM_UNKNOWN) > > Tested on x86_64 using make -j 8 check-fortran. > > OK to commit? > > [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 represents a common. The patch > was modified to allow global identifiers that represent a common > block. > > 2020-09-04 Steven G. Kargl > Mark Eggleston > > 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 known as is not a common > block name. > > 2020-09-04 Mark Eggleston > > gcc/testsuite/ > > PR fortran/95614 > * gfortran.dg/pr95614_1.f90: New test. > * gfortran.dg/pr95614_2.f90: New test. > > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [PATCH] Fortran : ICE in build_field PR95614
**ping** On 04/09/2020 08:35, Mark Eggleston wrote: Please find attached a fix for PR95614. The original patch was by Steve Kargl. The original patch resulted in name clashes between global identifiers naming common blocks and local identifiers. According to the 2018 standard 19.3.1 Classes of local identifiers, item 2, a local identifier shall not be the same as a global identifier, however, there is an exception where the global identifier is a common block name. The change to the patch is: if (gsym && gsym->type != GSYM_UNKNOWN && gsym->type != GSYM_COMMON) instead of: if (gsym && gsym->type != GSYM_UNKNOWN) Tested on x86_64 using make -j 8 check-fortran. OK to commit? [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 represents a common. The patch was modified to allow global identifiers that represent a common block. 2020-09-04 Steven G. Kargl Mark Eggleston 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 known as is not a common block name. 2020-09-04 Mark Eggleston gcc/testsuite/ PR fortran/95614 * gfortran.dg/pr95614_1.f90: New test. * gfortran.dg/pr95614_2.f90: New test. -- https://www.codethink.co.uk/privacy.html
