[Bug fortran/105243] New: ICE in next_char, at fortran/io.cc:160

[Bug fortran/105243] New: ICE in next_char, at fortran/io.cc:160

[gscfq@t-online.de]

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

            Bug ID: 105243
           Summary: ICE in next_char, at fortran/io.cc:160
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gscfq@t-online.de
  Target Milestone: ---

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

[Bug fortran/105243] ICE in next_char, at fortran/io.cc:160

[gscfq@t-online.de]

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

G. Steinmetz <gscfq@t-online.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-invalid-code

--- Comment #1 from G. Steinmetz <gscfq@t-online.de> ---

$ 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

[Bug fortran/105243] ICE in next_char, at fortran/io.cc:160

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-05-16
           Priority|P3                          |P4
                 CC|                            |kargl at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #2 from kargl at gcc dot gnu.org ---
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

[Bug fortran/105243] ICE in next_char, at fortran/io.cc:160

[anlauf at gcc dot gnu.org]

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?

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.)

[Bug fortran/105243] ICE in next_char, at fortran/io.cc:160

[anlauf at gcc dot gnu.org]

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
(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.

[Bug fortran/105243] ICE in next_char, at fortran/io.cc:160

[sgk at troutmask dot apl.washington.edu]

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.

[Bug fortran/105243] ICE in next_char, at fortran/io.cc:160

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
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?

[Bug fortran/105243] ICE in next_char, at fortran/io.cc:160

[anlauf at gcc dot gnu.org]

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

[Bug fortran/105243] ICE in next_char, at fortran/io.cc:160

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #8 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
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)

[Bug fortran/105243] ICE in next_char, at fortran/io.cc:160

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |anlauf at gcc dot gnu.org
                 CC|                            |anlauf at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #9 from anlauf at gcc dot gnu.org ---
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.

[Bug fortran/105243] ICE in next_char, at fortran/io.cc:160

[anlauf at gcc dot gnu.org]

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

--- Comment #10 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2022-June/057972.html

[Bug fortran/105243] ICE in next_char, at fortran/io.cc:160

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #11 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
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.

[Bug fortran/105243] ICE in next_char, at fortran/io.cc:160

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
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>

[Bug fortran/105243] ICE in next_char, at fortran/io.cc:160

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits <cvs-commit at gcc dot 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)

[Bug fortran/105243] ICE in next_char, at fortran/io.cc:160

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
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)

[Bug fortran/105243] ICE in next_char, at fortran/io.cc:160

[cvs-commit at gcc dot gnu.org]

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

--- Comment #15 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
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)

[Bug fortran/105243] ICE in next_char, at fortran/io.cc:160

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
   Target Milestone|---                         |10.5
         Resolution|---                         |FIXED

--- Comment #16 from anlauf at gcc dot gnu.org ---
Fixed on all open branches.  Closing.

Thanks for the report!