| Summary: | [OOP] ICE with ALLOCATE and SOURCE= TRANSPOSE/RESHAPE | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Tobias Burnus <burnus> |
| Component: | fortran | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | NEW --- | ||
| Severity: | normal | CC: | burnus, damian, janus, pault |
| Priority: | P3 | Keywords: | ice-on-valid-code |
| Version: | 4.8.0 | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Known to work: | 7.1.0 | |
| Known to fail: | 5.5.0, 6.3.0 | Last reconfirmed: | 2013-01-08 00:00:00 |
| Attachments: | Failing test case | ||
> allocate(y(3,3), source=transpose(x))
This one fails in trans-stmt.c's gfc_trans_allocate for expr3:
gfc_init_se (&se_sz, NULL);
gfc_conv_expr_reference (&se_sz, code->expr3);
which invokes gfc_conv_variable as se->ss is NULL and se->descriptor_only is false:
case REF_ARRAY:
...
gfc_conv_array_ref (se, &ref->u.ar, sym, &expr->where);
which expects se->ss != NULL.
If one sets descriptor_only = 1, it will fail for:
memsize = gfc_vtable_size_get (classexpr);
From trans-stmt.c's gfc_trans_allocate
/* Evaluate expr3 just once if not a variable. */
...
&& code->expr3->ts.type == BT_CLASS
&& code->expr3->expr_type != EXPR_VARIABLE)
...
classexpr = gfc_evaluate_now (classexpr, &se.pre);
I think we should handle intrinsic functions in a special way as they never change the actual type BT_CLASS; thus, the actual type can be taken from the actual argument of RESHAPE/TRANSPOSE. (Though, check that "transfer(f())" doesn't evaluate "f" twice.)
(If one skips that if block, the ICE occurs in gfc_array_allocate when obtaining the size via gfc_array_init_size.)
Confirmed. I'm guessing the code below is another manifestation of the this bug:
$ cat ice-on-pack-unlimited-polymorphic.f90
contains
subroutine array_to_vector(array)
class(*), allocatable :: vector(:),array(:,:)
allocate(vector,source=pack(array,.true.))
end subroutine
end
$ gfortran ice-on-pack-unlimited-polymorphic.f90
ice-on-pack-unlimited-polymorphic.f90:4:0:
allocate(vector,source=pack(array,.true.))
1
internal compiler error: Segmentation fault: 11
ice-on-pack-unlimited-polymorphic.f90:4:0: internal compiler error: Abort trap: 6
gfortran: internal compiler error: Abort trap: 6 (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://trac.macports.org/newticket> for instructions.
$ gfortran --version
GNU Fortran (MacPorts gcc6 6-20150621_0) 6.0.0 20150621 (experimental)
...
$ sudo port select --set gcc mp-gcc5
Selecting 'mp-gcc5' for 'gcc' succeeded. 'mp-gcc5' is now active.
$ gfortran ice-on-pack-unlimited-polymorphic.f90
ice-on-pack-unlimited-polymorphic.f90:4:13:
allocate(vector,source=pack(array,.true.))
1
Error: Array specification required in ALLOCATE statement at (1)
I'm guessing the code below is another manifestation of the this bug:
$ cat ice-on-pack-unlimited-polymorphic.f90
contains
subroutine array_to_vector(array)
class(*), allocatable :: vector(:),array(:,:)
allocate(vector,source=pack(array,.true.))
end subroutine
end
$ gfortran ice-on-pack-unlimited-polymorphic.f90
ice-on-pack-unlimited-polymorphic.f90:4:0:
allocate(vector,source=pack(array,.true.))
1
internal compiler error: Segmentation fault: 11
ice-on-pack-unlimited-polymorphic.f90:4:0: internal compiler error: Abort trap: 6
gfortran: internal compiler error: Abort trap: 6 (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://trac.macports.org/newticket> for instructions.
$ gfortran --version
GNU Fortran (MacPorts gcc6 6-20150621_0) 6.0.0 20150621 (experimental)
...
$ sudo port select --set gcc mp-gcc5
Selecting 'mp-gcc5' for 'gcc' succeeded. 'mp-gcc5' is now active.
$ gfortran ice-on-pack-unlimited-polymorphic.f90
ice-on-pack-unlimited-polymorphic.f90:4:13:
allocate(vector,source=pack(array,.true.))
1
Error: Array specification required in ALLOCATE statement at (1)
Related to/duplicate of pr57117? With the patch in comment 5 of pr57117, the original code in comment 0 compiles but segfault at run time, while the original test in pr57117 does not (altho there is a problem with "allocate(y(3,3), source=transpose(x))". Compiling the test in comment 4 still gives an ICE at r229494 with the patch pr55824_1.f90:4:0: allocate(vector,source=pack(array,.true.)) 1 internal compiler error: in wide_int_to_tree, at tree.c:1480 Seems to be working in GCC 7+. (In reply to Andrew Pinski from comment #7) > Seems to be working in GCC 7+. Hmmm! It seems to me to be broken from 7-branch through the current mainline. Cheers Paul |
Created attachment 29057 [details] Failing test case The following example by Reinhold Bader gives an ICE. It uses CLASS(*) but allegedly the issue also occurs with nonunlimited polymorphics. The ICE occurs for: class(*), allocatable :: x(:,:), y(:,:), z(:) ... allocate(y(3,3), source=transpose(x)) ! <<< ICE ... allocate(z(9), source=reshape(x, (/ 9 /))) ! <<< ICE Backtraces: 0x5fd05b gfc_conv_scalarized_array_ref ../../gcc/fortran/trans-array.c:3042 0x5fda71 gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_symbol*, locus*) ../../gcc/fortran/trans-array.c:3168 0x62ba7f gfc_conv_variable ../../gcc/fortran/trans-expr.c:1795 and 0x62794d gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec<tree_node*, va_gc, vl_embed>*) ../../gcc/fortran/trans-expr.c:4955 0x63f7b5 conv_generic_with_optional_char_arg ../../gcc/fortran/trans-intrinsic.c:4526 0x63f7b5 gfc_conv_intrinsic_function(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-intrinsic.c:6306 0x628488 gfc_conv_function_expr ../../gcc/fortran/trans-expr.c:5524 0x628488 gfc_conv_expr(gfc_se*, gfc_expr*)