[Bug fortran/50410] New: ICE in record_reference

[Bug fortran/50410] New: ICE in record_reference

[zeccav at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410

             Bug #: 50410
           Summary: ICE in record_reference
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: zeccav@gmail.com


Created attachment 25286
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25286
just compile it

ICE in record_reference

[Bug fortran/50410] [4.6/4.7 Regression] ICE in record_reference

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011-09-15
            Summary|ICE in record_reference     |[4.6/4.7 Regression] ICE in
                   |                            |record_reference
     Ever Confirmed|0                           |1

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-09-15 11:08:55 UTC ---
Confirmed on 4.6.1 and trunk:

pr50410.f90:7:0: internal compiler error: in record_reference, at
cgraphbuild.c:67

no ICE on 4.4.6 and 4.5.3 (no error). g95 gives the following error:

In file pr50410.f90:6

      data  u%g /1/
            1
Error: Can't dereference POINTER in DATA statement at (1)

[Bug fortran/50410] [4.6/4.7 Regression] ICE in record_reference

[zeccav at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410

--- Comment #2 from Vittorio Zecca <zeccav at gmail dot com> 2011-09-18 17:38:10 UTC ---
The following produces a Segmentation fault in gfc_conv_structure (r178925)

      type t
       integer g
      end type
      type(t) :: u=t(1)
      data u%g /2/
      end

[Bug fortran/50410] [4.6/4.7 Regression] ICE in record_reference

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410

--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-09-18 18:20:57 UTC ---
The problem for the code in comment #2 seems different:
it gives a segmentation fault with 4.6.1 and trunk and an ICE with 4.4.6 and
4.5.3:

f951: internal compiler error: in formalize_structure_cons, at
fortran/data.c:(756|755)

g95 gives the following error

In file pr50410_1.f90:5

      data u%g /2/
           1
Error: Variable 'u' at (1) already has an initialization

[Bug fortran/50410] [4.6/4.7 Regression] ICE in record_reference

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410

kargl at gcc dot gnu.org changed:

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

--- Comment #4 from kargl at gcc dot gnu.org 2011-09-18 23:31:53 UTC ---
(In reply to comment #2)
> The following produces a Segmentation fault in gfc_conv_structure (r178925)
> 
>       type t
>        integer g
>       end type
>       type(t) :: u=t(1)
>       data u%g /2/
>       end

The code is invalid and so gfortran can do anything that it
wishes, including segfault.

5.2.5 Data Statement

  ...
  A variable, or part of a variable, shall not be explicitly
  initialized more than once in a program.
  ...

[Bug fortran/50410] [4.6/4.7 Regression] ICE in record_reference

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-invalid-code
                 CC|                            |janus at gcc dot gnu.org

--- Comment #5 from janus at gcc dot gnu.org 2011-09-21 16:58:29 UTC ---
(In reply to comment #4)
> The code is invalid and so gfortran can do anything that it
> wishes, including segfault.

Well, no. An ICE on invalid code may not be as bad as an ICE on valid code, but
it's still a bug. gfortran should give a meaningful error message.

[Bug fortran/50410] [4.6/4.7 Regression] ICE in record_reference

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.6.2

[Bug fortran/50410] [4.6/4.7 Regression] ICE in record_reference

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4

[Bug fortran/50410] [4.6/4.7 Regression] ICE in record_reference

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410

Tobias Burnus <burnus at gcc dot gnu.org> changed:

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

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-10-17 16:38:28 UTC ---
To check:
- Pointer attribute in the part ref - or an allocate attribute.
- Whether there is already some initialization.
  If one uses a constructor, it affects the whole variable,
  but mixing different data statements is OK as long as different
  parts are initialized.
- If one directly access the variable: Pointer init is only OK for null()

Example for the last item:
      integer, pointer :: u
      data u /1/  ! Accepted, but probably shouldn't
      ! data u/null()/ ! Probably OK (and currently accepted).
      end

I think it could be sufficient to check decl.c's var_element though it might
fail if one initializes a DT piecewise; if so, one needs to add a check to
data.c or modify something else in decl.c

[Bug fortran/50410] [4.6/4.7 Regression] ICE in record_reference

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410

--- Comment #7 from kargl at gcc dot gnu.org 2011-10-17 17:36:33 UTC ---
(In reply to comment #2)
> The following produces a Segmentation fault in gfc_conv_structure (r178925)
> 
>       type t
>        integer g
>       end type
>       type(t) :: u=t(1)
>       data u%g /2/
>       end

The following patch removes the seqfault.  If one adds
'print *, u%g' before end and compiles the resulting
program, then one gets 1.  This is acceptable, IMHO,
because the code is invalid.


Index: trans-expr.c
===================================================================
--- trans-expr.c        (revision 180099)
+++ trans-expr.c        (working copy)
@@ -4747,7 +4747,7 @@ gfc_conv_structure (gfc_se * se, gfc_exp
   cm = expr->ts.u.derived->components;

   for (c = gfc_constructor_first (expr->value.constructor);
-       c; c = gfc_constructor_next (c), cm = cm->next)
+       c && cm; c = gfc_constructor_next (c), cm = cm->next)
     {
       /* Skip absent members in default initializers and allocatable
         components.  Although the latter have a default initializer

[Bug fortran/50410] [4.6/4.7 Regression] ICE in record_reference

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410

--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-10-17 21:20:25 UTC ---
Created attachment 25534
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25534
Draft patch

The attached patch should fix all issues; however, I think the error message
text can be improved. Additionally, one should re-check the standard and add
some more test cases.

[Bug fortran/50410] [4.6/4.7 Regression] ICE in record_reference

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410

--- Comment #9 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-10-18 07:23:10 UTC ---
>From the standard:
"C568 (R536) A data-i-do-object or a variable that appears as a
 data-stmt-object shall not be an object designator in which a
 pointer appears other than as the entire rightmost part-ref."

"C567 (R536) A variable whose designator appears as a
 data-stmt-object or a data-i-do-object shall not be a dummy
 argument, accessed by use or host association, in a named
 common block unless the DATA statement is in a block data
 program unit, in blank common, a function name, a function
 result name, an automatic object, or an allocatable variable."

To be fixed beyond the patch of attachment 25534
* ICE below (1) for init of DT with default init
* ICE below (2) with structure constructor, which initializes a pointer
(plus: test cases, revised error message wording)
* (3) Pointer init in DATA: Also "initial-data-target" is allowed

For the pointer init, see also PR 45290.

! =============== (1) =======================
module m
type t
  integer :: a  = 7
end type t
type t2
  integer :: b
end type t2
end module m

use m
implicit type(t)(x), type(t2)(y)
! ICE in trans:
! Invalid as "nonpointer object has default initialization"
DATA x%a/8/

! OK:
!DATA y%b/5/
!type(t2) :: y = t2(7) ! { dg-error "initializer already appears in a DATA
statement" }
end
! ============= (2) =========================
module m
  type t
    integer :: a
    integer, pointer :: bar
  end type t
end module m

subroutine test()
  use m
  type(t) :: x ! = t(4, null()) ! OK
 DATA x/t(4, null())/ ! ICE in the middle end
end subroutine test
! ============= (3) =========================
type t
  integer, pointer :: ptr
end type t
integer, target, save :: tgt

! Version A:
!type(t) :: x = t(tgt)
! Rejected with "has not been declared or is a variable,
!         which does not reduce to a constant expression"

! Version 2
type(t) :: x
DATA x%ptr /tgt/ ! error "must be a PARAMETER in DATA statement"

tgt = 7
print *, ptr
end

[Bug fortran/50410] [4.6/4.7 Regression] ICE in record_reference

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.6.2                       |4.6.3

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-10-26 17:13:37 UTC ---
GCC 4.6.2 is being released.

[Bug fortran/50410] [4.6/4.7 Regression] ICE in record_reference

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410

--- Comment #11 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-02 12:30:42 UTC ---
See also RFC patch: http://gcc.gnu.org/ml/fortran/2011-10/msg00136.html
and reply: http://gcc.gnu.org/ml/fortran/2011-10/msg00138.html

[Bug fortran/50410] [4.6/4.7 Regression] ICE in record_reference

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.6.3                       |4.6.4

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-03-01 14:38:32 UTC ---
GCC 4.6.3 is being released.

[Bug fortran/50410] [4.7/4.8/4.9 Regression] ICE in record_reference

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.6.4                       |4.7.4

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-04-12 15:16:50 UTC ---
GCC 4.6.4 has been released and the branch has been closed.

[Bug fortran/50410] [4.7/4.8/4.9/4.10 Regression] ICE in record_reference

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.4                       |4.8.4

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
The 4.7 branch is being closed, moving target milestone to 4.8.4.

[Bug fortran/50410] [4.8/4.9/5 Regression] ICE in record_reference

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.4                       |4.8.5

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.8.4 has been released.

[Bug fortran/50410] [4.8/4.9/5/6 Regression] ICE in record_reference

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.5                       |4.9.3

--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.

[Bug fortran/50410] [4.9/5/6 Regression] ICE in record_reference

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.3 has been released.

[Bug fortran/50410] [4.9/5/6 Regression] ICE in record_reference

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.3                       |4.9.4

[Bug fortran/50410] [4.9/5/6 Regression] ICE in record_reference

[zeccav at gmail dot com]

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

--- Comment #19 from Vittorio Zecca <zeccav at gmail dot com> ---
ICE still there in 5.2.0

[Bug fortran/50410] [8/9/10/11 Regression] ICE in record_reference, pointer variable in data statement

[zeccav at gmail dot com]

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

--- Comment #37 from Vittorio Zecca <zeccav at gmail dot com> ---
Fixed in 10.1.1.

[Bug fortran/50410] [8/9/10/11 Regression] ICE in record_reference, pointer variable in data statement

[zeccav at gmail dot com]

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

Vittorio Zecca <zeccav at gmail dot com> changed:

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

--- Comment #38 from Vittorio Zecca <zeccav at gmail dot com> ---
Fixed in 10.1.1.
Closing the issue.

[Bug fortran/50410] [8/9/10/11 Regression] ICE in record_reference, pointer variable in data statement

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |kargl at gcc dot gnu.org
         Resolution|FIXED                       |---
   Target Milestone|8.5                         |11.0

--- Comment #39 from kargl at gcc dot gnu.org ---
The bug is not fixed.  The code from comment #3

% cat a.f90
     type t
       integer g
      end type
      type(t) :: u=t(1)
      data u%g /2/
      end
troutmask:sgk[205] gfcx -c a.f90
a.f90:1:0:

    1 |      type t
      | 
internal compiler error: Segmentation fault
0xdf6e3a crash_signal
        ../../gccx/gcc/toplev.c:328
0x8acbae gfc_conv_structure(gfc_se*, gfc_expr*, int)
        ../../gccx/gcc/fortran/trans-expr.c:8528
0x8c1f37 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
        ../../gccx/gcc/fortran/trans-expr.c:7679
0x8a0020 gfc_get_symbol_decl(gfc_symbol*)
        ../../gccx/gcc/fortran/trans-decl.c:1892
0x8a33e5 generate_local_decl
        ../../gccx/gcc/fortran/trans-decl.c:5894
0x85a0e2 do_traverse_symtree
        ../../gccx/gcc/fortran/symbol.c:4165
0x8a454c generate_local_vars
        ../../gccx/gcc/fortran/trans-decl.c:6100
0x8a454c gfc_generate_function_code(gfc_namespace*)
        ../../gccx/gcc/fortran/trans-decl.c:6758
0x81e516 translate_all_program_units
        ../../gccx/gcc/fortran/parse.c:6302
0x81e516 gfc_parse_file()
        ../../gccx/gcc/fortran/parse.c:6541
0x871858 gfc_be_parse_file
        ../../gccx/gcc/fortran/f95-lang.c:210

The code in the first example in comment #9 also causes an ICE.

Codes z1.f90, z2.f90, and z3.f90 in comment #23 cause ICEs.

[Bug fortran/50410] [8/9/10/11 Regression] ICE in record_reference, pointer variable in data statement

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

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

--- Comment #40 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #39)
> The bug is not fixed.  The code from comment #3
> 
> % cat a.f90
>      type t
>        integer g
>       end type
>       type(t) :: u=t(1)
>       data u%g /2/
>       end

The patch

diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index b7c568e90e6..02caf992dfd 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -8543,7 +8543,7 @@ gfc_conv_structure (gfc_se * se, gfc_expr * expr, int
init)
   cm = expr->ts.u.derived->components;

   for (c = gfc_constructor_first (expr->value.constructor);
-       c; c = gfc_constructor_next (c), cm = cm->next)
+       c && cm; c = gfc_constructor_next (c), cm = cm->next)
     {
       /* Skip absent members in default initializers and allocatable
         components.  Although the latter have a default initializer

fixes the ICE, but does not detect the double initialization.

> The code in the first example in comment #9 also causes an ICE.

This one then works and produces the expected error.

> Codes z1.f90, z2.f90, and z3.f90 in comment #23 cause ICEs.

Only z1 ICEs, z2 and z3 produce error messages.

[Bug fortran/50410] [8/9/10/11 Regression] ICE in record_reference, pointer variable in data statement

[dominiq at lps dot ens.fr]

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

--- Comment #41 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
In my working tree I had the following patch

--- /opt/gcc/_clean-svn//gcc/fortran/trans-expr.c       2020-01-05
11:44:35.000000000 +0100
+++ /opt/gcc/work-cvs/gcc/fortran/trans-expr.c  2020-01-05 11:45:38.000000000
+0100
@@ -8366,7 +8366,7 @@ gfc_trans_structure_assign (tree dest, g
     gfc_init_se (&se, NULL);

   for (c = gfc_constructor_first (expr->value.constructor);
-       c; c = gfc_constructor_next (c), cm = cm->next)
+       c && cm; c = gfc_constructor_next (c), cm = cm->next)
     {
       /* Skip absent members in default initializers.  */
       if (!c->expr && !cm->attr.allocatable)
@@ -8447,6 +8447,7 @@ gfc_trans_structure_assign (tree dest, g
                                              expr->ts.u.derived, init);
       gfc_add_expr_to_block (&block, tmp);
     }
+  gcc_assert (!c);
   return gfc_finish_block (&block);
 }

@@ -8519,7 +8520,7 @@ gfc_conv_structure (gfc_se * se, gfc_exp
   cm = expr->ts.u.derived->components;

   for (c = gfc_constructor_first (expr->value.constructor);
-       c; c = gfc_constructor_next (c), cm = cm->next)
+       c && cm; c = gfc_constructor_next (c), cm = cm->next)
     {
       /* Skip absent members in default initializers and allocatable
         components.  Although the latter have a default initializer
@@ -8564,6 +8565,11 @@ gfc_conv_structure (gfc_se * se, gfc_exp
          CONSTRUCTOR_APPEND_ELT (v, cm->backend_decl, val);
        }
     }
+  /* gcc_assert (!c); */
+  if (c)
+    /* gfc_error ("Invalid DATA statement at %C.");
+    gfc_error ("Invalid DATA statement at %L.", &expr->where); */
+    gfc_error ("Invalid DATA statement at %L.", &gfc_current_locus);

   se->expr = build_constructor (type, v);
   if (init)

I have never seen the first assert triggering and I never found a way to emit a
better error message.

[Bug fortran/50410] [8/9/10/11 Regression] ICE in record_reference, pointer variable in data statement

[anlauf at gcc dot gnu.org]

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

--- Comment #42 from anlauf at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #41)
> In my working tree I had the following patch

This still ICEs on comment#23 z1.

Slightly rewriting that case, one gets a reasonable error message:

program p
  type ta
     integer :: a
  end type ta
  type t
     type(ta), pointer :: b
  end type t
  type(t) :: u = t(ta(1))
end

pr50410_23x.f90:8:19:

    8 |   type(t) :: u = t(ta(1))
      |                   1
Error: The element in the structure constructor at (1), for pointer component
'b' should be a POINTER or a TARGET


Digging further, one sees that the error is generated for z1 but not emitted.
The following patch does the magic (not regtested):

diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 8daa7bb8d06..0a995ec3ae7 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -3087,6 +3087,9 @@ gfc_reduce_init_expr (gfc_expr *expr)
     t = gfc_check_init_expr (expr);
   gfc_init_expr_flag = false;

+  if (gfc_error_check())
+    return false;
+
   if (!t || !expr)
     return false;

[Bug fortran/50410] [8/9/10/11 Regression] ICE in record_reference, pointer variable in data statement

[anlauf at gcc dot gnu.org]

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

--- Comment #43 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #42)
> The following patch does the magic (not regtested):
> 
> diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
> index 8daa7bb8d06..0a995ec3ae7 100644
> --- a/gcc/fortran/expr.c
> +++ b/gcc/fortran/expr.c
> @@ -3087,6 +3087,9 @@ gfc_reduce_init_expr (gfc_expr *expr)
>      t = gfc_check_init_expr (expr);
>    gfc_init_expr_flag = false;
>  
> +  if (gfc_error_check())
> +    return false;
> +
>    if (!t || !expr)
>      return false;

This produces lots of regressions.  So this is apparently not the right place.

[Bug fortran/50410] [8/9/10/11/12 Regression] ICE in record_reference, pointer variable in data statement

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.0                        |11.2

--- Comment #44 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 11.1 has been released, retargeting bugs to GCC 11.2.

[Bug fortran/50410] [9/10/11/12 Regression] ICE in record_reference, pointer variable in data statement

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.2                        |11.3

--- Comment #45 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 11.2 is being released, retargeting bugs to GCC 11.3

[Bug fortran/50410] [9/10/11/12 Regression] ICE in record_reference, pointer variable in data statement

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.3                        |11.4

--- Comment #46 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 11.3 is being released, retargeting bugs to GCC 11.4.

[Bug fortran/50410] [10/11/12/13/14 Regression] ICE in record_reference, pointer variable in data statement

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.4                        |11.5

--- Comment #47 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 11.4 is being released, retargeting bugs to GCC 11.5.

[Bug fortran/50410] [11/12/13/14 Regression] ICE in record_reference, pointer variable in data statement

[anlauf at gcc dot gnu.org]

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

--- Comment #48 from anlauf at gcc dot gnu.org ---
Created attachment 55666
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55666&action=edit
Inremental patch

This is a cut-down and revised version of the patch by Tobias that deals with
invalid allocatable and pointer components in data statements, and adjusted
to F2018, and fixing the issue mentioned by Steve.

I've removed the other part that tries to detect the double initialization.
I think this is the wrong place as is would not detect e.g. the following:

program p
  type t
     integer :: g
  end type t
  type(t) :: u
  data u /t(3)/
  data u%g /2/
end

A better-suited place is probably the loop in gfc_assign_data_value, but
find_con_by_component seems not to be able to handle the current situation.

[Bug fortran/50410] [11/12/13/14 Regression] ICE in record_reference, pointer variable in data statement

[cvs-commit at gcc dot gnu.org]

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

--- Comment #49 from GCC 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:6fb253a25dff13253d63553f02e0fe72c5e3ab4e

commit r14-9720-g6fb253a25dff13253d63553f02e0fe72c5e3ab4e
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Thu Mar 28 22:34:40 2024 +0100

    Fortran: fix NULL pointer dereference on overlapping initialization
[PR50410]

    gcc/fortran/ChangeLog:

            PR fortran/50410
            * trans-expr.cc (gfc_conv_structure): Check for NULL pointer.

    gcc/testsuite/ChangeLog:

            PR fortran/50410
            * gfortran.dg/data_initialized_4.f90: New test.

[Bug fortran/50410] [11/12/13/14 Regression] ICE in record_reference, pointer variable in data statement

[cvs-commit at gcc dot gnu.org]

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

--- Comment #50 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Harald Anlauf
<anlauf@gcc.gnu.org>:

https://gcc.gnu.org/g:250990298fb792635d9895e7642ccedbc2dd39d4

commit r13-8505-g250990298fb792635d9895e7642ccedbc2dd39d4
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Thu Mar 28 22:34:40 2024 +0100

    Fortran: fix NULL pointer dereference on overlapping initialization
[PR50410]

    gcc/fortran/ChangeLog:

            PR fortran/50410
            * trans-expr.cc (gfc_conv_structure): Check for NULL pointer.

    gcc/testsuite/ChangeLog:

            PR fortran/50410
            * gfortran.dg/data_initialized_4.f90: New test.

    (cherry picked from commit 6fb253a25dff13253d63553f02e0fe72c5e3ab4e)

[Bug fortran/50410] [11/12/13/14 Regression] ICE in record_reference, pointer variable in data statement

[cvs-commit at gcc dot gnu.org]

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

--- Comment #51 from GCC 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:cb72fbd49e1f0c1cbdf8a9e97860063b19b1f95e

commit r12-10299-gcb72fbd49e1f0c1cbdf8a9e97860063b19b1f95e
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Thu Mar 28 22:34:40 2024 +0100

    Fortran: fix NULL pointer dereference on overlapping initialization
[PR50410]

    gcc/fortran/ChangeLog:

            PR fortran/50410
            * trans-expr.cc (gfc_conv_structure): Check for NULL pointer.

    gcc/testsuite/ChangeLog:

            PR fortran/50410
            * gfortran.dg/data_initialized_4.f90: New test.

    (cherry picked from commit 6fb253a25dff13253d63553f02e0fe72c5e3ab4e)

[Bug fortran/50410] [11/12/13/14 Regression] ICE in record_reference, pointer variable in data statement

[cvs-commit at gcc dot gnu.org]

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

--- Comment #52 from GCC 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:1611acc1f72cad30c7ecccb5c85246836c1d0299

commit r11-11299-g1611acc1f72cad30c7ecccb5c85246836c1d0299
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Thu Mar 28 22:34:40 2024 +0100

    Fortran: fix NULL pointer dereference on overlapping initialization
[PR50410]

    gcc/fortran/ChangeLog:

            PR fortran/50410
            * trans-expr.c (gfc_conv_structure): Check for NULL pointer.

    gcc/testsuite/ChangeLog:

            PR fortran/50410
            * gfortran.dg/data_initialized_4.f90: New test.

    (cherry picked from commit 6fb253a25dff13253d63553f02e0fe72c5e3ab4e)

[Bug fortran/50410] ICE in record_reference, pointer variable in data statement

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[11/12/13/14 Regression]    |ICE in record_reference,
                   |ICE in record_reference,    |pointer variable in data
                   |pointer variable in data    |statement
                   |statement                   |
           Keywords|                            |diagnostic

--- Comment #53 from anlauf at gcc dot gnu.org ---
Removing the regression marker after the ICEs on the testcases are all
resolved except:

- comment#24 testcase z5: this is a coarray issue and has nothing to do
  with DATA initialization --> should be moved to a separate PR

- missing diagnostics for overlapping initialization of DT components,
  and some sub-optimal error messages that could be improved

So let's treat this PR further as any regular one.