public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/106047] New: ICE in structure_alloc_comps, at fortran/trans-array.cc:9574
@ 2022-06-21 18:49 gscfq@t-online.de
  2022-06-22 20:44 ` [Bug fortran/106047] " anlauf at gcc dot gnu.org
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: gscfq@t-online.de @ 2022-06-21 18:49 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 106047
           Summary: ICE in structure_alloc_comps, at
                    fortran/trans-array.cc:9574
           Product: gcc
           Version: 13.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(:), allocatable :: c
   end type
   type(t) :: x
   integer :: n = storage_size(x)
end


$ gfortran-13-20220619 -c z1.f90
z1.f90:5:15:

    5 |    type(t) :: x
      |               1
internal compiler error: Segmentation fault
0xcd90df crash_signal
        ../../gcc/toplev.cc:322
0x7c6620 structure_alloc_comps
        ../../gcc/fortran/trans-array.cc:9574
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

* [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

end of thread, other threads:[~2022-06-24  6:12 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).