Affects versions down to at least r5 : $ cat z1.f90 program p type t character(3) :: c = '(a)' end type class(t), parameter :: x = 1. print x%c end $ gfortran-12-20220410 -c z1.f90 f951: internal compiler error: Segmentation fault 0xcce66f crash_signal ../../gcc/toplev.cc:322 0x713d78 next_char ../../gcc/fortran/io.cc:160 0x713ef6 next_char ../../gcc/fortran/io.cc:214 0x713ef6 next_char_not_space ../../gcc/fortran/io.cc:208 0x713f2a format_lex ../../gcc/fortran/io.cc:236 0x714522 format_lex ../../gcc/fortran/io.cc:617 0x714522 check_format ../../gcc/fortran/io.cc:619 0x716ab7 check_format_string ../../gcc/fortran/io.cc:1338 0x716ab7 match_io ../../gcc/fortran/io.cc:4409 0x71a1ba gfc_match_print() ../../gcc/fortran/io.cc:4450 0x74aa31 match_word ../../gcc/fortran/parse.cc:67 0x750563 decode_statement ../../gcc/fortran/parse.cc:539 0x75099a next_free ../../gcc/fortran/parse.cc:1397 0x75099a next_statement ../../gcc/fortran/parse.cc:1629 0x751f2b parse_spec ../../gcc/fortran/parse.cc:4168 0x7550cc parse_progunit ../../gcc/fortran/parse.cc:6210 0x756791 gfc_parse_file() ../../gcc/fortran/parse.cc:6755 0x7a438f gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:216
$ cat z2.f90 program p type t character(3) :: c = '(a)' end type class(t), parameter :: x = 1. print *, x%c end $ cat z3.f90 program p type t character(3) :: c = '(a)' end type class(t), parameter :: x = 1. call s(x%c) end $ gfortran-12-20220410 -c z2.f90 z2.f90:5:27: 5 | class(t), parameter :: x = 1. | 1 Error: CLASS variable 'x' at (1) cannot have the PARAMETER attribute z2.f90:5:29: 5 | class(t), parameter :: x = 1. | 1 Error: Cannot convert REAL(4) to CLASS() at (1) f951: internal compiler error: Segmentation fault 0xe7751f crash_signal ../../gcc/toplev.cc:322 0x734da3 free_expr0 ../../gcc/fortran/expr.cc:462 0x734e48 gfc_free_expr(gfc_expr*) ../../gcc/fortran/expr.cc:531 0x7cfd51 gfc_free_statement(gfc_code*) ../../gcc/fortran/st.cc:86 0x7cfef2 gfc_free_statements(gfc_code*) ../../gcc/fortran/st.cc:318 0x7cff14 gfc_free_statements(gfc_code*) ../../gcc/fortran/st.cc:317 0x7d6a24 gfc_free_namespace(gfc_namespace*&) ../../gcc/fortran/symbol.cc:4041 0x7d7159 gfc_symbol_done_2() ../../gcc/fortran/symbol.cc:4105 0x76e548 gfc_done_2() ../../gcc/fortran/misc.cc:382 0x798198 translate_all_program_units ../../gcc/fortran/parse.cc:6688 0x798198 gfc_parse_file() ../../gcc/fortran/parse.cc:6956 0x7e626f gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:216
This fixes the problem. Someone that regularly use git will need to commit it. diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc index bd586e75008..6712efd6ec8 100644 --- a/gcc/fortran/decl.cc +++ b/gcc/fortran/decl.cc @@ -6283,6 +6283,15 @@ gfc_match_data_decl (void) goto cleanup; } + /* F2018:C708. */ + if (current_ts.type == BT_CLASS && current_attr.flavor == FL_PARAMETER) + { + gfc_error ("CLASS entity at %C shall be a dummy argument or have the " + "ALLOCATABLE or POINTER attribute."); + m = MATCH_ERROR; + goto cleanup; + } + ok: /* If we have an old-style character declaration, and no new-style attribute specifications, then there a comma is optional between
(In reply to kargl from comment #2) > This fixes the problem. Someone that regularly use git will need to commit > it. Are you sure this is the right solution? Consider: program p type t character(3) :: c = '(a)' end type class(t), parameter :: x = t() class(*), parameter :: y = t() print x%c end Intel accepts the code, and I haven't found anything prohibiting the above. F2018 has: C850 An entity with the PARAMETER attribute shall not be a variable, a coarray, or a procedure. I think we see here an area where gfortran lacks newer features. We shouldn't simply reject PARAMETER and CLASS. (There are a couple of related PRs.)
(In reply to anlauf from comment #3) > F2018 has: > > C850 An entity with the PARAMETER attribute shall not be a variable, a > coarray, or a procedure. Or we see here an disagreement between C850 and C708.
On Mon, May 16, 2022 at 08:27:24PM +0000, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105243 > > --- Comment #3 from anlauf at gcc dot gnu.org --- > (In reply to kargl from comment #2) > > This fixes the problem. Someone that regularly use git will need to commit > > it. > > Are you sure this is the right solution? > I quoted the F2018 standard constraint. C708 An entity declared with the CLASS keyword shall be a dummy argument or have the ALLOCATABLE or POINTER attribute. class(t), parameter :: y would seem to be missing all of the three listed attributes.
On Mon, May 16, 2022 at 10:16:51PM +0000, sgk at troutmask dot apl.washington.edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105243 > > --- Comment #5 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- > On Mon, May 16, 2022 at 08:27:24PM +0000, anlauf at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105243 > > > > --- Comment #3 from anlauf at gcc dot gnu.org --- > > (In reply to kargl from comment #2) > > > This fixes the problem. Someone that regularly use git will need to commit > > > it. > > > > Are you sure this is the right solution? > > > > I quoted the F2018 standard constraint. > > C708 An entity declared with the CLASS keyword shall be a dummy > argument or have the ALLOCATABLE or POINTER attribute. > > class(t), parameter :: y > > would seem to be missing all of the three listed attributes. > I'll also add 7.3.2.3 CLASS type specifier The CLASS type specifier is used to declare polymorphic entities. A polymorphic entity is a data entity that is able to be of differing dynamic types during program execution. Does is make sense to given a named constant the polymorphic property?
(In reply to Steve Kargl from comment #6) > > I quoted the F2018 standard constraint. > > > > C708 An entity declared with the CLASS keyword shall be a dummy > > argument or have the ALLOCATABLE or POINTER attribute. > > > > class(t), parameter :: y > > > > would seem to be missing all of the three listed attributes. You're right here. > I'll also add > > 7.3.2.3 CLASS type specifier > > The CLASS type specifier is used to declare polymorphic entities. > A polymorphic entity is a data entity that is able to be of differing > dynamic types during program execution. > > Does is make sense to given a named constant the polymorphic property? Well, I could imagine named constants that do not have a type (e.g. when using CLASS(*)), as well as named constants that refer to an extensible type. The F2023 draft even has CLASSOF. Where will this finally lead... I think I should ask the Intel people why their compiler accepts program p type t integer :: i = 1 end type t type(t), parameter :: a = t() ! Legal class(t), parameter :: b = t() ! Likely not class(*), parameter :: c = t() ! ... class(*), parameter :: d = 1 ! ... end
On Tue, May 17, 2022 at 07:56:18PM +0000, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105243 > > --- Comment #7 from anlauf at gcc dot gnu.org --- > (In reply to Steve Kargl from comment #6) > > > I quoted the F2018 standard constraint. > > > > > > C708 An entity declared with the CLASS keyword shall be a dummy > > > argument or have the ALLOCATABLE or POINTER attribute. > > > > > > class(t), parameter :: y > > > > > > would seem to be missing all of the three listed attributes. > > You're right here. > > > I'll also add > > > > 7.3.2.3 CLASS type specifier > > > > The CLASS type specifier is used to declare polymorphic entities. > > A polymorphic entity is a data entity that is able to be of differing > > dynamic types during program execution. > > > > Does is make sense to given a named constant the polymorphic property? > > Well, I could imagine named constants that do not have a type (e.g. when > using CLASS(*)), as well as named constants that refer to an extensible > type. The F2023 draft even has CLASSOF. Where will this finally lead... > > I think I should ask the Intel people why their compiler accepts > > program p > type t > integer :: i = 1 > end type t > type(t), parameter :: a = t() ! Legal > class(t), parameter :: b = t() ! Likely not > class(*), parameter :: c = t() ! ... > class(*), parameter :: d = 1 ! ... > end > None of these are dummy arguments. None of these have the ALLOCATABLE attribute. None of these have the POINTER attribute. These all violate C708. For 4.2 Conformance, 2 A processor conforms to this document if: (3) it contains the capability to detect and report the use within a submitted program unit of a form or relationship that is not permitted by the numbered syntax rules or constraints, including the deleted features described in Annex B; Furthermore, the PARAMETER attribute conflicts with a dummy argument, ALLOCATABLE attribute, and POINTER attribute. At least, gfortran believes there is a conflict. subroutine foo0(x) class(*), parameter :: x end subroutine foo0 subroutine foo1() type t integer :: i = 1 end type t class(t), parameter, allocatable :: a end subroutine foo1 subroutine foo2() type t integer :: i = 1 end type t class(t), parameter, pointer :: a end subroutine foo2 % gfortran11 -c a.f90 a.f90:2:26: 2 | class(*), parameter :: x | 1 Error: PARAMETER attribute conflicts with DUMMY attribute at (1) a.f90:9:22: 9 | class(t), parameter, allocatable :: a | 1 Error: PARAMETER attribute conflicts with ALLOCATABLE attribute at (1) a.f90:16:31: 16 | class(t), parameter, pointer :: a | 1 Error: PARAMETER attribute conflicts with POINTER attribute at (1)
Steve, when using your patch from comment#2 and moving it up slightly, it will also improve error handling for unlimited polymorphic entities. This fixes a few more PRs. Taking.
Submitted: https://gcc.gnu.org/pipermail/fortran/2022-June/057972.html
On Wed, Jun 29, 2022 at 07:42:30PM +0000, anlauf at gcc dot gnu.org wrote: > > when using your patch from comment#2 and moving it up slightly, it will > also improve error handling for unlimited polymorphic entities. This fixes > a few more PRs. > Saw you email to fortran@. Thanks for grabbing it. I think it's ok to commit, but I fully understand wanting to get another set of eyes on it.
The master branch has been updated by Harald Anlauf <anlauf@gcc.gnu.org>: https://gcc.gnu.org/g:4c233cabbe388a6b8957c1507e129090e9267ceb commit r13-1370-g4c233cabbe388a6b8957c1507e129090e9267ceb Author: Harald Anlauf <anlauf@gmx.de> Date: Wed Jun 29 21:36:17 2022 +0200 Fortran: error recovery on invalid CLASS(), PARAMETER declarations [PR105243] gcc/fortran/ChangeLog: PR fortran/103137 PR fortran/103138 PR fortran/103693 PR fortran/105243 * decl.cc (gfc_match_data_decl): Reject CLASS entity declaration when it is given the PARAMETER attribute. gcc/testsuite/ChangeLog: PR fortran/103137 PR fortran/103138 PR fortran/103693 PR fortran/105243 * gfortran.dg/class_58.f90: Fix test. * gfortran.dg/class_73.f90: New test. Co-authored-by: Steven G. Kargl <kargl@gcc.gnu.org>
The releases/gcc-12 branch has been updated by Harald Anlauf <anlauf@gcc.gnu.org>: https://gcc.gnu.org/g:d870ce1a112c0cbdff6172346a4a164503d92573 commit r12-8544-gd870ce1a112c0cbdff6172346a4a164503d92573 Author: Harald Anlauf <anlauf@gmx.de> Date: Wed Jun 29 21:36:17 2022 +0200 Fortran: error recovery on invalid CLASS(), PARAMETER declarations [PR105243] gcc/fortran/ChangeLog: PR fortran/103137 PR fortran/103138 PR fortran/103693 PR fortran/105243 * decl.cc (gfc_match_data_decl): Reject CLASS entity declaration when it is given the PARAMETER attribute. gcc/testsuite/ChangeLog: PR fortran/103137 PR fortran/103138 PR fortran/103693 PR fortran/105243 * gfortran.dg/class_58.f90: Fix test. * gfortran.dg/class_73.f90: New test. Co-authored-by: Steven G. Kargl <kargl@gcc.gnu.org> (cherry picked from commit 4c233cabbe388a6b8957c1507e129090e9267ceb)
The releases/gcc-11 branch has been updated by Harald Anlauf <anlauf@gcc.gnu.org>: https://gcc.gnu.org/g:5c293d9abc4b14e987a574fc11666809a2b8b8da commit r11-10107-g5c293d9abc4b14e987a574fc11666809a2b8b8da Author: Harald Anlauf <anlauf@gmx.de> Date: Wed Jun 29 21:36:17 2022 +0200 Fortran: error recovery on invalid CLASS(), PARAMETER declarations [PR105243] gcc/fortran/ChangeLog: PR fortran/103137 PR fortran/103138 PR fortran/103693 PR fortran/105243 * decl.c (gfc_match_data_decl): Reject CLASS entity declaration when it is given the PARAMETER attribute. gcc/testsuite/ChangeLog: PR fortran/103137 PR fortran/103138 PR fortran/103693 PR fortran/105243 * gfortran.dg/class_58.f90: Fix test. * gfortran.dg/class_73.f90: New test. Co-authored-by: Steven G. Kargl <kargl@gcc.gnu.org> (cherry picked from commit 4c233cabbe388a6b8957c1507e129090e9267ceb)
The releases/gcc-10 branch has been updated by Harald Anlauf <anlauf@gcc.gnu.org>: https://gcc.gnu.org/g:290147c4c8e3d9d1f13297b511d3a0afb5e952d4 commit r10-10882-g290147c4c8e3d9d1f13297b511d3a0afb5e952d4 Author: Harald Anlauf <anlauf@gmx.de> Date: Wed Jun 29 21:36:17 2022 +0200 Fortran: error recovery on invalid CLASS(), PARAMETER declarations [PR105243] gcc/fortran/ChangeLog: PR fortran/103137 PR fortran/103138 PR fortran/103693 PR fortran/105243 * decl.c (gfc_match_data_decl): Reject CLASS entity declaration when it is given the PARAMETER attribute. gcc/testsuite/ChangeLog: PR fortran/103137 PR fortran/103138 PR fortran/103693 PR fortran/105243 * gfortran.dg/class_58.f90: Fix test. * gfortran.dg/class_73.f90: New test. Co-authored-by: Steven G. Kargl <kargl@gcc.gnu.org> (cherry picked from commit 4c233cabbe388a6b8957c1507e129090e9267ceb)
Fixed on all open branches. Closing. Thanks for the report!