[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #31 from anlauf at gcc dot gnu.org ---
I've just checked the various comments.

What's left:

- comment#2 : the testcase still fails.  See also comment#7 about the invalid
  partial initialization

- lack of diagnostics of overlapping initialization

There is also some overlap with pr50410.

The ICEs appear fixed, in particular the one in comment#31.

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #30 from Vittorio Zecca  ---
On the following source code I still have the ICE:

  type t
   integer g
  end type
  type(t) :: u=t(1)
  data u%g /2/ ! should emit diagnostic here
  end

gfortran -S gfbug63.f
gfbug63.f:6:72:

6 |   type t
  |   
1
internal compiler error: Segmentation fault
0xe7a01f crash_signal
../../gcc-150221/gcc/toplev.c:327
0x94a42d gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gcc-150221/gcc/fortran/trans-expr.c:8746
0x94a01f gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc-150221/gcc/fortran/trans-expr.c:7895
0x92ed34 gfc_get_symbol_decl(gfc_symbol*)
../../gcc-150221/gcc/fortran/trans-decl.c:1917
0x931c03 generate_local_decl
../../gcc-150221/gcc/fortran/trans-decl.c:5950
0x8ead22 do_traverse_symtree
../../gcc-150221/gcc/fortran/symbol.c:4170
0x932d93 generate_local_vars
../../gcc-150221/gcc/fortran/trans-decl.c:6156
0x932d93 gfc_generate_function_code(gfc_namespace*)
../../gcc-150221/gcc/fortran/trans-decl.c:6815
0x8afaee translate_all_program_units
../../gcc-150221/gcc/fortran/parse.c:6351
0x8afaee gfc_parse_file()
../../gcc-150221/gcc/fortran/parse.c:6620
0x90112f gfc_be_parse_file
../../gcc-150221/gcc/fortran/f95-lang.c:212
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #29 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r11-7564-gbd85b4dd2dd7b00b6342ed1e33fb48035a3dcb61
Author: Harald Anlauf 
Date:   Mon Mar 8 21:59:20 2021 +0100

PR fortran/49278 - ICE when combining DATA with default initialization

A variable with the PARAMETER attribute may not appear in a DATA statement.

gcc/fortran/ChangeLog:

PR fortran/49278
* data.c (gfc_assign_data_value): Reject variable with PARAMETER
attribute in DATA statement.

gcc/testsuite/ChangeLog:

PR fortran/49278
* gfortran.dg/parameter_data.f90: New test.

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #28 from anlauf at gcc dot gnu.org ---
Patch for accepts-invalid / ice-on-invalid-code (parameter + data) part:

https://gcc.gnu.org/pipermail/fortran/2021-March/055768.html

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[kargl at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #27 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #26)
> (In reply to kargl from comment #23)
> > (In reply to anlauf from comment #21)
> > > There's also valid code that ICEs, and invalid code that is silently
> > > accepted.
> > > 
> > > Invalid code:
> > > 
> > > program p
> > >   implicit none
> > >   integer, parameter :: b = 1
> > >   data b / 2 /
> > >   print *, b
> > > end
> > > 
> > > Instead of being rejected, this prints:
> > >1
> > 
> > You need know about gfortran's extensions.
> > 
> > % gfcx -Wall -o z -std=f95 a.f90
> > a.f90:4:12:
> > 
> > 4 |   data b / 2 /
> >   |1
> > Error: GNU Extension: re-initialization of 'b' at (1)
> 
> I hope you noticed the PARAMETER, which should have been caught by
> -fno-writable-parameters ... ;-)

Yes, I did.  Hopefully, you noticed the word EXTENSION.  As an 
extension, gfortran swallows the code. :-)

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #26 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #23)
> (In reply to anlauf from comment #21)
> > There's also valid code that ICEs, and invalid code that is silently
> > accepted.
> > 
> > Invalid code:
> > 
> > program p
> >   implicit none
> >   integer, parameter :: b = 1
> >   data b / 2 /
> >   print *, b
> > end
> > 
> > Instead of being rejected, this prints:
> >1
> 
> You need know about gfortran's extensions.
> 
> % gfcx -Wall -o z -std=f95 a.f90
> a.f90:4:12:
> 
> 4 |   data b / 2 /
>   |1
> Error: GNU Extension: re-initialization of 'b' at (1)

I hope you noticed the PARAMETER, which should have been caught by
-fno-writable-parameters ... ;-)

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #25 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #24)
> (In reply to anlauf from comment #21)

> Looks like the patch from comment #2 that I posted 9 years ago. LoL.
> Bug must not hit real code too often as no one has fixed it.

Well, there are multiple places with almost identical un-code.

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[kargl at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #24 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #21)
> 
> And after fixing an obvious NULL pointer dereference,
> 
> diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
> index 37a0c85fa30..783a0bbddcc 100644
> --- a/gcc/fortran/trans-decl.c
> +++ b/gcc/fortran/trans-decl.c
> @@ -5520,7 +5520,7 @@ check_constant_initializer (gfc_expr *expr,
> gfc_typespec *ts, bool array,
> return false;
>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)
> {
>   if (!c->expr || cm->attr.allocatable)
> continue;
> 

Looks like the patch from comment #2 that I posted 9 years ago. LoL.
Bug must not hit real code too often as no one has fixed it.

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[kargl at gcc dot gnu.org via Gcc-bugs]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #23 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #21)
> There's also valid code that ICEs, and invalid code that is silently
> accepted.
> 
> Invalid code:
> 
> program p
>   implicit none
>   integer, parameter :: b = 1
>   data b / 2 /
>   print *, b
> end
> 
> Instead of being rejected, this prints:
>1

You need know about gfortran's extensions.

% gfcx -Wall -o z -std=f95 a.f90
a.f90:4:12:

4 |   data b / 2 /
  |1
Error: GNU Extension: re-initialization of 'b' at (1)

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #22 from anlauf at gcc dot gnu.org ---
The -fdump-fortran-original of the last example in comment#21 contains

  symtree: 'z'   || symbol: 'z'
type spec : (DERIVED t)
attributes: (VARIABLE IMPLICIT-SAVE DATA)
value: t(4. , 3.)

so perhaps we should properly overwrite or merge with the default initializer
instead of appending?

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
   Keywords||ice-on-valid-code,
   ||wrong-code

--- Comment #21 from anlauf at gcc dot gnu.org ---
There's also valid code that ICEs, and invalid code that is silently accepted.

Invalid code:

program p
  implicit none
  integer, parameter :: b = 1
  data b / 2 /
  print *, b
end

Instead of being rejected, this prints:
   1

One could catch this one in gfc_assign_data_value, but I haven't found out
yet how to get this right with derived type components, so there's possibly
a better place.

And after fixing an obvious NULL pointer dereference,

diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 37a0c85fa30..783a0bbddcc 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -5520,7 +5520,7 @@ check_constant_initializer (gfc_expr *expr, gfc_typespec
*ts, bool array,
return false;
   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)
{
  if (!c->expr || cm->attr.allocatable)
continue;

we arrive at wrong code on valid input:

program p
  implicit none
  type t
 real :: a
  end type t
  type(t) :: z = t(4.0)
  data z%a /3.0/
  print *, z%a
end

This now prints
   4.

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[kargl at gcc dot gnu.org]

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

--- Comment #20 from kargl at gcc dot gnu.org ---
*** Bug 91939 has been marked as a duplicate of this bug. ***

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[gs...@t-online.de]

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

--- Comment #19 from G. Steinmetz  ---

Adding a "parameter" attribute :


$ cat z8.f90
program p
   type t
  real :: a
  real :: b = 2.0
   end type
   type(t), parameter :: z = t(4.0, 5.0)
   data z%a /3.0/
end


$ cat z9.f90
program p
   type t
  real :: a
   end type
   type(t), parameter :: z = t(4.0)
   data z%a /3.0/
end


$ gfortran-9-20181021 -c z9.f90
z9.f90:7:0:

7 | end
  |
internal compiler error: Segmentation fault
0xb1c86f crash_signal
../../gcc/toplev.c:325
0x6d9481 check_constant_initializer
../../gcc/fortran/trans-decl.c:5198
0x6d9ef4 gfc_emit_parameter_debug_info
../../gcc/fortran/trans-decl.c:5262
0x6a80f2 do_traverse_symtree
../../gcc/fortran/symbol.c:4151
0x6e53fa gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6671
0x673426 translate_all_program_units
../../gcc/fortran/parse.c:6125
0x673426 gfc_parse_file()
../../gcc/fortran/parse.c:6328
0x6ba3ff gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204


Adding "pointer" instead of "parameter" gives pr50410 comment 0.

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[gs...@t-online.de]

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

--- Comment #18 from G. Steinmetz  ---

Update and simplified a bit, ICEs down to at least version 5 :


$ cat z1.f90
module m
   type t
  sequence
  real :: a
  real :: b = 2.0
   end type
   type(t) :: z
   data z%a /3.0/
end


$ cat z2.f90
program p
   type t
  real :: a
  real :: b = 2.0
   end type
   type(t) :: z
   data z%a /3.0/
end


$ gfortran-9-20181021 -c z2.f90
z2.f90:1:0:

1 | program p
  |
internal compiler error: Segmentation fault
0xb1c86f crash_signal
../../gcc/toplev.c:325
0x6ec0cd gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gcc/fortran/trans-expr.c:7865
0x6fca91 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc/fortran/trans-expr.c:7027
0x6e1647 gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1824
0x6e3ec7 generate_local_decl
../../gcc/fortran/trans-decl.c:5596
0x6a80f2 do_traverse_symtree
../../gcc/fortran/symbol.c:4151
0x6e4fe4 generate_local_vars
../../gcc/fortran/trans-decl.c:5796
0x6e4fe4 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6440
0x673426 translate_all_program_units
../../gcc/fortran/parse.c:6125
0x673426 gfc_parse_file()
../../gcc/fortran/parse.c:6328
0x6ba3ff gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||gs...@t-online.de

--- Comment #17 from Dominique d'Humieres  ---
*** Bug 86220 has been marked as a duplicate of this bug. ***

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[juergen.reuter at desy dot de]

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

--- Comment #16 from Jürgen Reuter  ---
In addition to what Tobias remarked, NAG now gives a clear error message:

NAG Fortran Compiler Release 6.1(Tozai) Build 6138
Error: data.f90, line 13: Object TRLKOLD of type ACTIVE is default-initialised,
therefore subobject TRLKOLD%V is not permitted in a DATA statement

Intel in v18.0.1 still does not give a compilation or runtime error.

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #15 from Jürgen Reuter  ---
I just stumbled over this again while reading c.l.f. This still is ICEing with
8.0.1. If it is inconsistent code as the c.l.f. discussion and the J3 answer to
the interpretation request point out, this should be caught with an exception.

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[dominiq at lps dot ens.fr]

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

--- Comment #14 from Dominique d'Humieres  ---
> I think that 1 << 31 is undefined because "1" is assumed (signed) int.
> Maybe it should be 1u << 31 ?

I have tried it, but it does not work.

> Anyway on 6.1.0 I have no runtime error message.

This due to

#define bit_AVX512VL unsigned (1 << 31)

in gcc/config/i386/cpuid.h. AFAICT it is also present for gcc-6.

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[zeccav at gmail dot com]

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

--- Comment #13 from Vittorio Zecca  ---
I think that 1 << 31 is undefined because "1" is assumed (signed) int.
Maybe it should be 1u << 31 ?

Anyway on 6.1.0 I have no runtime error message.

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[dominiq at lps dot ens.fr]

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

--- Comment #12 from Dominique d'Humieres  ---
The ICE is gone with the patch in comment 2, however I get at run time

../../../work/libgcc/config/i386/cpuinfo.c:346:17: runtime error: left shift of
1 by 31 places cannot be represented in type 'int'

(instrumented trunk).

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[zeccav at gmail dot com]

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

--- Comment #11 from Vittorio Zecca  ---
Same ICE in 6.1.0

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

--- Comment #9 from Dominique d'Humieres  ---
*** Bug 58233 has been marked as a duplicate of this bug. ***

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
Related to pr50410.

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[thenlich at users dot sourceforge.net]

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

Thomas Henlich thenlich at users dot sourceforge.net changed:

   What|Removed |Added

 CC||thenlich at users dot
   ||sourceforge.net

--- Comment #7 from Thomas Henlich thenlich at users dot sourceforge.net 
2011-06-30 12:26:30 UTC ---
J3 subgroup has answered this:

http://j3-fortran.org/doc/meeting/195/11-201r1.txt

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[burnus at gcc dot gnu.org]

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

Tobias Burnus burnus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.30 12:33:12
 Ever Confirmed|0   |1

--- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-30 
12:33:12 UTC ---
(In reply to comment #7)
 J3 subgroup has answered this:
 http://j3-fortran.org/doc/meeting/195/11-201r1.txt

Thanks. In a nutshell: It is invalid - the standard does not allow to combine
partial default-initialization with partial DATA initialization.

It is not a constraint, hence, the compiler is not required to diagnose it, but
I think it should - rather than ICEing ...

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-14 
12:32:02 UTC ---
I have now filled an interpretation request (J3/11-201) - in time for WG5 and
J3 meeting (m195), which is end of June. Let's see what J3/WG5 will decide. Cf.
http://j3-fortran.org/doc/meeting/195/11-201.txt [Remember: Updates will be put
in files named 11-201r1.txt, ...r2.txt, etc.]

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-07 
09:17:05 UTC ---
(In reply to comment #3)
 (In reply to comment #2)
  The following aborts.  Note sure if it is conforming.

 Hence, it seems to be valid, but I wouldn't mind if someone could cross check

I have now asked at c.l.f:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/8d3b9a3813ef914a#

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-08 
05:55:26 UTC ---
(In reply to comment #4)
 I have now asked at c.l.f:

Richard and Dick think the standard is very unclear; they are slightly inclined
to conclude that it is invalid, but suggest to fill an interpretation request,
which I will do.