[Bug fortran/102595] New: ICE in var_element, at fortran/decl.c:298

[Bug fortran/102595] New: ICE in var_element, at fortran/decl.c:298

[gscfq@t-online.de]

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

            Bug ID: 102595
           Summary: ICE in var_element, at fortran/decl.c:298
           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: ---

Started with r10 :


$ cat z1.f90
program p
   complex, parameter :: x(0) = 2
   data x%im /3.0/
end


$ cat z2.f90
program p
   complex, parameter :: x(1) = 2
   data x%im /3.0/
end


$ gfortran-12-20211003 -c z2.f90
z2.f90:3:12:

    3 |    data x%im /3.0/
      |            1
Error: PARAMETER 'x' shall not appear in a DATA statement at (1)


$ gfortran-12-20211003 -c z1.f90
f951: internal compiler error: Segmentation fault
0xd41bdf crash_signal
        ../../gcc/toplev.c:331
0x77b0ed var_element
        ../../gcc/fortran/decl.c:298
0x77d4c4 top_var_list
        ../../gcc/fortran/decl.c:338
0x77d4c4 gfc_match_data()
        ../../gcc/fortran/decl.c:655
0x7eb6f1 match_word
        ../../gcc/fortran/parse.c:65
0x7f065e decode_statement
        ../../gcc/fortran/parse.c:469
0x7f13ca next_free
        ../../gcc/fortran/parse.c:1384
0x7f13ca next_statement
        ../../gcc/fortran/parse.c:1616
0x7f2aeb parse_spec
        ../../gcc/fortran/parse.c:4151
0x7f58bc parse_progunit
        ../../gcc/fortran/parse.c:6117
0x7f7041 gfc_parse_file()
        ../../gcc/fortran/parse.c:6658
0x843f3f gfc_be_parse_file
        ../../gcc/fortran/f95-lang.c:216

[Bug fortran/102595] ICE in var_element, at fortran/decl.c:298

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-10-05
     Ever confirmed|0                           |1

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

May be related to pr102599 in some way or other.

[Bug fortran/102595] ICE in var_element, at fortran/decl.c:298 since r10-5607-gde89b5748d68b76b

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org,
                   |                            |marxin at gcc dot gnu.org
            Summary|ICE in var_element, at      |ICE in var_element, at
                   |fortran/decl.c:298          |fortran/decl.c:298 since
                   |                            |r10-5607-gde89b5748d68b76b

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r10-5607-gde89b5748d68b76b.

[Bug fortran/102595] ICE in var_element, at fortran/decl.c:298 since r10-5607-gde89b5748d68b76b

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
Created attachment 52053
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52053&action=edit
patch

[Bug fortran/102595] ICE in var_element, at fortran/decl.c:298 since r10-5607-gde89b5748d68b76b

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Comment on attachment 52053
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52053
patch

This patch fixes the problem in the PR and addresses a few
niggles I found as I poked gfortran.  Some of those errors
don't occur without this patch.

program p
   complex, parameter :: x(0) = 2
!   complex :: x(0) = 2            ! { dg-error "more values than variables" }
!   complex :: x(1) = 2            ! { dg-error "already is initialized" }
!   complex :: x = 2               ! { dg-error "already is initialized" }
!   complex :: x(1)                ! Works (as expected?)
!   complex :: x(0)                ! { dg-error "more values than variables" }
   data x%re /3.0/
   print *, x%re
end

[Bug fortran/102595] ICE in var_element, at fortran/decl.c:298 since r10-5607-gde89b5748d68b76b

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #52053|0                           |1
        is obsolete|                            |

--- Comment #5 from kargl at gcc dot gnu.org ---
Created attachment 52054
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52054&action=edit
new patch

This is a better patch and now deals with the legal code

program foo
   complex a
   data a%re, a%im /1., 2./
   print *, a%re, a%im
end program foo

and the invalid code

program foo
   complex a
   data a%re, a%re /1., 2./
   print *, a%re, a%im
end program foo

[Bug fortran/102595] ICE in var_element, at fortran/decl.c:298 since r10-5607-gde89b5748d68b76b

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jerry DeLisle <jvdelisle@gcc.gnu.org>:

https://gcc.gnu.org/g:cdc6bf44eec295805ae29a8aaddafd111de01c8e

commit r13-4934-gcdc6bf44eec295805ae29a8aaddafd111de01c8e
Author: Steve Kargl <kargl@gcc.gnu.org>
Date:   Mon Dec 26 14:07:04 2022 -0800

    Modify checks to avoid referencing NULL pointer.

    Update test cases with error messages that changed as a result.

    gcc/fortran/ChangeLog:

            PR fortran/102595
            * decl.cc (attr_decl1): Guard against NULL pointer.
            * parse.cc (match_deferred_characteristics): Include BT_CLASS in
check for
            derived being undefined.

    gcc/testsuite/ChangeLog:

            PR fortran/102595
            * gfortran.dg/class_result_4.f90: Update error message check.
            * gfortran.dg/pr85779_3.f90: Update error message check.

[Bug fortran/102595] ICE in var_element, at fortran/decl.c:298 since r10-5607-gde89b5748d68b76b

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at gcc dot gnu.org

--- Comment #7 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
(In reply to CVS Commits from comment #6)

The above commit should have been for PR102331.

[Bug fortran/102595] ICE in var_element, at fortran/decl.c:298 since r10-5607-gde89b5748d68b76b

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
I started to do some variations on the z1.f90 case:

program p
   complex, parameter :: x(0) = 2
   !data x%im /3.0/
   print *, x
end

Running this prints a blank line;

Looking at the -fdump-tree-original shows:

      parm.1.span = 8;
      parm.1.dtype = {.elem_len=8, .rank=1, .type=4};
      parm.1.dim[0].lbound = 1;
      parm.1.dim[0].ubound = 0;
      parm.1.dim[0].stride = 1;
      parm.1.data = (void *) &x[0];
      parm.1.offset = -1;

Is it valid to have an ubound less than the lbound?

program p
   complex, parameter :: x(1) = 2
   !data x%im /3.0/
   print *, x
end

The z2 case prints what is expected.  It looks like we need to catch something
in the parameter declaration before the data statement so that it is not
garbage later.

.. to be continued ..

[Bug fortran/102595] ICE in var_element, at fortran/decl.c:298 since r10-5607-gde89b5748d68b76b

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #9 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Sun, Jan 15, 2023 at 08:07:16PM +0000, jvdelisle at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102595
> 
> --- Comment #8 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
> I started to do some variations on the z1.f90 case:
> 
> program p
>    complex, parameter :: x(0) = 2

x is a zero-sized array.

program p
   complex, parameter :: x(0) = 2
   print *, size(x)
end program p

[Bug fortran/102595] ICE in var_element, at fortran/decl.c:298 since r10-5607-gde89b5748d68b76b

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |jvdelisle at gcc dot gnu.org

--- Comment #10 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
The following appears to catch it correctly.  The previous spot I removed after
spotting while checking the addition to primary.cc.  I keep the error message
similar so that existing tests in gfortrn.dg pass without changing.

diff --git a/gcc/fortran/data.cc b/gcc/fortran/data.cc
index 443d35da9cf..d29eb12c1b1 100644
--- a/gcc/fortran/data.cc
+++ b/gcc/fortran/data.cc
@@ -244,13 +244,6 @@ gfc_assign_data_value (gfc_expr *lvalue, gfc_expr *rvalue,
mpz_t index,
                    "array-element nor a scalar-structure-component";

   symbol = lvalue->symtree->n.sym;
-  if (symbol->attr.flavor == FL_PARAMETER)
-    {
-      gfc_error ("PARAMETER %qs shall not appear in a DATA statement at %L",
-                symbol->name, &lvalue->where);
-      return false;
-    }
-
   init = symbol->value;
   last_ts = &symbol->ts;
   last_con = NULL;
diff --git a/gcc/fortran/primary.cc b/gcc/fortran/primary.cc
index 543d9cc0de4..158f039f225 100644
--- a/gcc/fortran/primary.cc
+++ b/gcc/fortran/primary.cc
@@ -4076,6 +4076,11 @@ match_variable (gfc_expr **result, int equiv_flag, int
host_flag)
          gfc_error ("Named constant at %C in an EQUIVALENCE");
          return MATCH_ERROR;
        }
+      if (gfc_in_match_data())
+       {
+         gfc_error ("PARAMETER %qs shall not appear in a DATA statement at
%C",
+                     sym->name);
+       }
       /* Otherwise this is checked for and an error given in the
         variable definition context checks.  */
       break;

[Bug fortran/102595] ICE in var_element, at fortran/decl.c:298 since r10-5607-gde89b5748d68b76b

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jerry DeLisle <jvdelisle@gcc.gnu.org>:

https://gcc.gnu.org/g:48f544ad5c98b668d8d345eaafcf09cc0bd44635

commit r13-5276-g48f544ad5c98b668d8d345eaafcf09cc0bd44635
Author: Jerry DeLisle <jvdelisle@gcc.gnu.org>
Date:   Sat Jan 21 15:19:57 2023 -0800

    fortran: [PR102595]

            PR fortran/102595

    gcc/fortran/ChangeLog:

            * data.cc (gfc_assign_data_value): Remove check for PARAMETER in
DATA.
            * primary.cc (match_variable): Add check for PARAMETER in DATA.

    gcc/testsuite/ChangeLog:

            * gfortran.dg/pr88048.f90: Adjust for changed error message.
            * gfortran.dg/parameter_data0.f90: New test.

[Bug fortran/102595] ICE in var_element, at fortran/decl.c:298 since r10-5607-gde89b5748d68b76b

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #12 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Fixed and closing.