* [Bug fortran/106047] ICE in structure_alloc_comps, at fortran/trans-array.cc:9574
2022-06-21 18:49 [Bug fortran/106047] New: ICE in structure_alloc_comps, at fortran/trans-array.cc:9574 gscfq@t-online.de
@ 2022-06-22 20:44 ` anlauf at gcc dot gnu.org
2022-06-23 15:41 ` gscfq@t-online.de
2022-06-24 6:12 ` gscfq@t-online.de
2 siblings, 0 replies; 4+ messages in thread
From: anlauf at gcc dot gnu.org @ 2022-06-22 20:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106047
anlauf at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2022-06-22
Ever confirmed|0 |1
CC| |anlauf at gcc dot gnu.org
--- Comment #1 from anlauf at gcc dot gnu.org ---
ICE confirmed. But it is really invalid? Intel & NAG accept it.
Part of the problem is gfc_element_size. It calculates a number that
is 8 for -m64, and 4 for -m32, likely sizeof (gfc_charlen_t), instead
of noticing that we have a descriptor for deferred length character.
(OTOH using character, allocatable :: c(:) seems to work, so maybe the
real issue is in gfc_typenode_for_spec).
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug fortran/106047] ICE in structure_alloc_comps, at fortran/trans-array.cc:9574
2022-06-21 18:49 [Bug fortran/106047] New: ICE in structure_alloc_comps, at fortran/trans-array.cc:9574 gscfq@t-online.de
2022-06-22 20:44 ` [Bug fortran/106047] " anlauf at gcc dot gnu.org
@ 2022-06-23 15:41 ` gscfq@t-online.de
2022-06-24 6:12 ` gscfq@t-online.de
2 siblings, 0 replies; 4+ messages in thread
From: gscfq@t-online.de @ 2022-06-23 15:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106047
--- Comment #2 from G. Steinmetz <gscfq@t-online.de> ---
Hmm, exploring some more test cases;
z2 gives same ICE, z3 prints 128, z4 gives an error, z5 is ok/works :
$ cat z2.f90
program p
type t
character(:), allocatable :: c
end type
type(t) :: x ! without = t()
integer, parameter :: n = storage_size(x)
end
$ cat z3.f90
program p
type t
character(:), allocatable :: c
end type
type(t), parameter :: x = t() ! that is t(null())
integer :: n = storage_size(x)
print *, n
end
$ cat z4.f90
program p
type t
character(:), allocatable :: c
end type
type(t), parameter :: x = t('abc') ! instead of t(null())
integer :: n = storage_size(x)
print *, n
end
$ cat z5.f90
program p
type t
character(:), allocatable :: c
end type
type(t) :: x
integer :: n
n = storage_size(x)
print *, n
end
---
Some examples without "type" :
$ cat zz1.f90
program p
character(:), allocatable :: c
integer :: n = storage_size(c)
print *, n
end
$ cat zz2.f90
program p
character(:), allocatable :: c
integer, parameter :: n = storage_size(c)
print *, n
end
$ cat zz3.f90
program p
character(:), allocatable :: c
print *, storage_size(c)
end
$ gfortran-13-20220619 -c zz1.f90
zz1.f90:3:31:
3 | integer :: n = storage_size(c)
| 1
Error: Parameter 'c' at (1) has not been declared or is a variable, which does
not reduce to a constant expression
$
$ gfortran-13-20220619 -c zz2.f90
zz2.f90:3:42:
3 | integer, parameter :: n = storage_size(c)
| 1
Error: Parameter 'c' at (1) has not been declared or is a variable, which does
not reduce to a constant expression
$
$ gfortran-13-20220619 zz3.f90 ; a.out
0
$
Via Compiler Explorer :
Latest ifort/ifx indeed compiles z1/2/3/5, rejects z4 with an error (ok).
Latest ifort/ifx rejects zz1/zz2 with an error, accepts zz3 and prints 0.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug fortran/106047] ICE in structure_alloc_comps, at fortran/trans-array.cc:9574
2022-06-21 18:49 [Bug fortran/106047] New: ICE in structure_alloc_comps, at fortran/trans-array.cc:9574 gscfq@t-online.de
2022-06-22 20:44 ` [Bug fortran/106047] " anlauf at gcc dot gnu.org
2022-06-23 15:41 ` gscfq@t-online.de
@ 2022-06-24 6:12 ` gscfq@t-online.de
2 siblings, 0 replies; 4+ messages in thread
From: gscfq@t-online.de @ 2022-06-24 6:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106047
G. Steinmetz <gscfq@t-online.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords|ice-on-invalid-code |ice-on-valid-code
--- Comment #3 from G. Steinmetz <gscfq@t-online.de> ---
Regarding these variants, all of them actually work :
$ cat zc1.f90
program p
type t
integer, allocatable :: c
end type
type(t) :: x
integer :: n = storage_size(x)
print *, n
end
$ cat zc2.f90
program p
type t
logical, allocatable :: c
end type
type(t) :: x
integer :: n = storage_size(x)
print *, n
end
$ cat zc3.f90
program p
type t
real, allocatable :: c
end type
type(t) :: x
integer :: n = storage_size(x)
print *, n
end
$ cat zc4.f90
program p
type t
character, allocatable :: c
end type
type(t) :: x
integer :: n = storage_size(x)
print *, n
end
$ cat zc5.f90
program p
type t
class(*), allocatable :: c
end type
type(t) :: x
integer :: n = storage_size(x)
print *, n
end
$ gfortran-13-20220619 zc1.f90 ; a.out
64
$ gfortran-13-20220619 zc2.f90 ; a.out
64
$ gfortran-13-20220619 zc3.f90 ; a.out
64
$ gfortran-13-20220619 zc4.f90 ; a.out
64
$ gfortran-13-20220619 zc5.f90 ; a.out
192
---
Testing additional options, there is never an ICE with zc5.f90,
but with the other ones e.g. at line 9129 instead of line 9574 :
$ gfortran-13-20220619 -c zc1.f90 -fcoarray=single
zc1.f90:5:15:
5 | type(t) :: x
| 1
internal compiler error: Segmentation fault
0xcd90df crash_signal
../../gcc/toplev.cc:322
0x7c4366 structure_alloc_comps
../../gcc/fortran/trans-array.cc:9129
0x7c7348 gfc_nullify_alloc_comp(gfc_symbol*, tree_node*, int, int)
../../gcc/fortran/trans-array.cc:10149
0x7c7348 gfc_trans_deferred_array(gfc_symbol*, gfc_wrapped_block*)
../../gcc/fortran/trans-array.cc:11206
0x7dabac gfc_trans_deferred_vars(gfc_symbol*, gfc_wrapped_block*)
../../gcc/fortran/trans-decl.cc:4994
0x7dd1a5 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.cc:7756
0x75f53e translate_all_program_units
../../gcc/fortran/parse.cc:6669
0x75f53e gfc_parse_file()
../../gcc/fortran/parse.cc:6956
0x7acb6f gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:229
^ permalink raw reply [flat|nested] 4+ messages in thread