[Bug fortran/82993] ICE in free_expr0, at fortran/expr.c:445

2018-12-25 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82993

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.5

--- Comment #6 from kargl at gcc dot gnu.org ---
Closing as fixed.

[Bug fortran/82993] ICE in free_expr0, at fortran/expr.c:445

2018-12-25 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82993

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #4)
> It seems one of my recent patches may have fixed this one.
> 
> % gfcx d.f90
> d.f90:5:30:
> 
> 5 |type(t), parameter :: z = 1
>   |  1
> Error: Incompatible initialization between a derived type entity and an
> entity with 'INTEGER(4)' type at (1)

I get the same error on branch-7 and branch-8, so the patch
has been back ported.

Likely fixed with

branch-7 r267180
branch-8 r267178
trunkr267177

r267177 | kargl | 2018-12-15 14:53:26 -0800 (Sat, 15 Dec 2018) | 11 lines

2019-12-15  Steven G. Kargl  

PR fortran/88138
* decl.c (variable_decl): Check that a derived isn't being assigned
an incompatible entity in an initialization.

[Bug fortran/82993] ICE in free_expr0, at fortran/expr.c:445

2018-12-25 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82993

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
It seems one of my recent patches may have fixed this one.

% gfcx d.f90
d.f90:5:30:

5 |type(t), parameter :: z = 1
  |  1
Error: Incompatible initialization between a derived type entity and an entity
with 'INTEGER(4)' type at (1)
d.f90:6:14:

6 |print *, z%a(1)
  |  1
Error: Symbol 'z' at (1) has no IMPLICIT type
d.f90:7:14:

7 |print *, z%a
  |  1
Error: Symbol 'z' at (1) has no IMPLICIT type

[Bug fortran/82993] ICE in free_expr0, at fortran/expr.c:445

2017-11-14 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82993

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 ---
(In reply to G. Steinmetz from comment #0)
> With a wrong parameter definition :
> 
> $ cat z1.f90
> program p
>type t
>   real :: a(3)
>end type
>type(t), parameter :: z = 1
>print *, z%a(1)
>print *, z%a
> end
> 
> 
> $ gfortran-8-20171112 -c z1.f90
> f951: internal compiler error: Segmentation fault
> 0xb61c7f crash_signal
> ../../gcc/toplev.c:325
> 0x69268b free_expr0
> ../../gcc/fortran/expr.c:445
> 0x6926ad gfc_free_expr(gfc_expr*)
> ../../gcc/fortran/expr.c:518
> 0x6efd59 gfc_match_rvalue(gfc_expr**)
> ../../gcc/fortran/primary.c:3250
> 0x6c655e match_primary
> ../../gcc/fortran/matchexp.c:157
> 0x6c655e match_level_1
> ../../gcc/fortran/matchexp.c:211
> 0x6c655e match_mult_operand
> ../../gcc/fortran/matchexp.c:267
> 0x6c67a8 match_add_operand
> ../../gcc/fortran/matchexp.c:356
> 0x6c6a3c match_level_2
> ../../gcc/fortran/matchexp.c:480
> 0x6c6b92 match_level_3
> ../../gcc/fortran/matchexp.c:551
> 0x6c6ca4 match_level_4
> ../../gcc/fortran/matchexp.c:599
> 0x6c6ca4 match_and_operand
> ../../gcc/fortran/matchexp.c:693
> 0x6c6e62 match_or_operand
> ../../gcc/fortran/matchexp.c:722
> 0x6c6f52 match_equiv_operand
> ../../gcc/fortran/matchexp.c:765
> 0x6c7042 match_level_5
> ../../gcc/fortran/matchexp.c:811
> 0x6c63b1 gfc_match_expr(gfc_expr**)
> ../../gcc/fortran/matchexp.c:870
> 0x6af7a9 match_io_element
> ../../gcc/fortran/io.c:3542
> 0x6af9f3 match_io_list
> ../../gcc/fortran/io.c:3581
> 0x6b4214 match_io
> ../../gcc/fortran/io.c:4242
> 0x6b592a gfc_match_print()
> ../../gcc/fortran/io.c:4298

Ugh.  This one is real ugly. :(

If both print statement are commented out, one gets

% gfcx -c a.f90
a.f90:5:28:

type(t), parameter :: z = 1
1
Error: Incompatible derived type in PARAMETER at (1)
a.f90:5:28:

type(t), parameter :: z = 1
1
Error: Can't convert INTEGER(4) to TYPE(t) at (1)

This is the good news!

If the first print statement is uncomment, we get Gerhard's
trace above.  If the first print is again commented out and
the second statement is uncommented, we get

% gfcx -c a.f90
a.f90:5:28:

type(t), parameter :: z = 1
1
Error: Incompatible derived type in PARAMETER at (1)
a.f90:5:28:

type(t), parameter :: z = 1
1
Error: Can't convert INTEGER(4) to TYPE(t) at (1)
(null):0: confused by earlier errors, bailing out

AFAICT, when the statement "type(t), parameter :: z = 1"
is rejected, the gfc_expr for z = 1 is not properly freed.
I see

(gdb) p *p
$8 = {op = EXEC_ASSIGN, block = 0x0, next = 0x0, loc = {nextc = 0x0, 
lb = 0x0}, here = 0x0, label1 = 0x0, label2 = 0x0, label3 = 0x0, 
  symtree = 0x0, expr1 = 0x201d837e0, expr2 = 0x0, expr3 = 0x0, expr4 = 0x0, 
  resolved_sym = 0x0, resolved_isym = 0x0, ext = {actual = 0x0, 
iterator = 0x0, alloc = {ts = {type = BT_UNKNOWN, kind = 0, u = {
  derived = 0x0, cl = 0x0, pad = 0}, interface = 0x0, 
is_c_interop = 0, is_iso_c = 0, f90_type = BT_UNKNOWN, 
deferred = false, interop_kind = 0x0}, list = 0x0, 
  arr_spec_from_expr3 = 0}, block = {ns = 0x0, assoc = 0x0, 
  case_list = 0x0}, open = 0x0, close = 0x0, filepos = 0x0, inquire = 0x0, 
wait = 0x0, dt = 0x0, forall_iterator = 0x0, which_construct = 0x0, 
stop_code = 0, entry = 0x0, oacc_declare = 0x0, omp_clauses = 0x0, 
omp_name = 0x0, omp_namelist = 0x0, omp_bool = false, 
omp_atomic = GFC_OMP_ATOMIC_UPDATE}, cycle_label = 0x0, exit_label = 0x0}

(gdb) p *p->expr1
$3 = {expr_type = EXPR_FUNCTION, ts = {type = BT_UNKNOWN, kind = 0, u = {
  derived = 0x0, cl = 0x0, pad = 0}, interface = 0x0, is_c_interop = 0, 
is_iso_c = 0, f90_type = BT_UNKNOWN, deferred = false, 
interop_kind = 0x0}, rank = 0, shape = 0x0, symtree = 0x201d805d0, 
  ref = 0x0, where = {nextc = 0x201dc50cc, lb = 0x201dc50a0}, base_expr = 0x0, 
  is_boz = 0, is_snan = 0, error = 0, user_operator = 0, mold = 0, 
  must_finalize = 0, representation = {length = 0, string = 0x0}, value = {
logical = 30934528, iokind = 30934528, integer = {{_mp_alloc = 30934528, 
_mp_size = 2, _mp_d = 0x0}}, real = {{_mpfr_prec = 8620869120, 
_mpfr_sign = 0, _mpfr_exp = 0, _mpfr_d = 0x0}}, complex = {{re = {{
_mpfr_prec = 8620869120, _mpfr_sign = 0, _mpfr_exp = 0, 
_mpfr_d = 0x0}}, im = {{_mpfr_prec = 0, _mpfr_sign = 0, 
_mpfr_exp = 0, _mpfr_d = 0x0, op = {op = 30934528, uop = 0x0, 
  op1 =

[Bug fortran/82993] ICE in free_expr0, at fortran/expr.c:445

2017-11-14 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82993

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-14
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (8.0).

[Bug fortran/82993] ICE in free_expr0, at fortran/expr.c:445

2017-11-14 Thread gs...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82993

G. Steinmetz  changed:

   What|Removed |Added

Summary|ICE free_expr0, at  |ICE in free_expr0, at
   |fortran/expr.c:445  |fortran/expr.c:445

--- Comment #1 from G. Steinmetz  ---

Similar tests :


$ cat  z3.f90
program p
   type t
  integer :: a(3)
   end type
   type(t), parameter :: z = 1.0
   print *, z%a(1)
   print *, z%a
end


$ cat  z5.f90
program p
   type t
  real :: a(3)
   end type
   type(t), parameter :: z = '1'
   print *, z%a(1)
   print *, z%a
end


$ cat  z6.f90
program p
   type t
  real :: a(3)
   end type
   type(t), parameter :: z = .true.
   print *, z%a(1)
   print *, z%a
end