[Bug fortran/45440] [F03] ALLOCATE with SOURCE gives an ICE (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440 vehre at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #13 from vehre at gcc dot gnu.org --- Fixed with r224477.
[Bug fortran/45440] [F03] ALLOCATE with SOURCE gives an ICE (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440 --- Comment #12 from vehre at gcc dot gnu.org --- Author: vehre Date: Mon Jun 15 10:08:04 2015 New Revision: 224477 URL: https://gcc.gnu.org/viewcvs?rev=224477&root=gcc&view=rev Log: gcc/testsuite/ChangeLog: 2015-06-15 Andre Vehreschild PR fortran/44672 PR fortran/45440 PR fortran/57307 * gfortran.dg/allocate_with_source_3.f90: Removed check for unimplemented error. * gfortran.dg/allocate_with_source_7.f08: New test. * gfortran.dg/allocate_with_source_8.f08: New test. gcc/fortran/ChangeLog: 2015-06-15 Andre Vehreschild PR fortran/44672 PR fortran/45440 PR fortran/57307 * gfortran.h: Extend gfc_code.ext.alloc to carry a flag indicating that the array specification has to be taken from expr3. * resolve.c (resolve_allocate_expr): Add F2008 notify and flag indicating source driven array spec. (resolve_allocate_deallocate): Check for source driven array spec, when array to allocate has no explicit array spec. * trans-array.c (gfc_array_init_size): Get lower and upper bound from a tree array descriptor, except when the source expression is an array-constructor which is fixed to be one-based. (retrieve_last_ref): Extracted from gfc_array_allocate(). (gfc_array_allocate): Enable allocate(array, source= array_expression) as specified by F2008:C633. (gfc_conv_expr_descriptor): Add class tree expression into the saved descriptor for class arrays. * trans-array.h: Add temporary array descriptor to gfc_array_allocate (). * trans-expr.c (gfc_conv_procedure_call): Special handling for _copy() routine translation, that comes without an interface. Third and fourth argument are now passed by value. * trans-stmt.c (gfc_trans_allocate): Get expr3 array descriptor for temporary arrays to allow allocate(array, source = array_expression) for array without array specification. Added: trunk/gcc/testsuite/gfortran.dg/allocate_with_source_7.f08 trunk/gcc/testsuite/gfortran.dg/allocate_with_source_8.f08 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-array.h trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/allocate_with_source_3.f90
[Bug fortran/45440] [F03] ALLOCATE with SOURCE gives an ICE (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING CC||vehre at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |vehre at gcc dot gnu.org --- Comment #11 from vehre at gcc dot gnu.org --- Taking this pr, because my patch at https://gcc.gnu.org/ml/fortran/2015-03/msg00168.html fixes the issue as reported by Dominique.
[Bug fortran/45440] [F03] ALLOCATE with SOURCE gives an ICE (segfault)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440 Sean Santos changed: What|Removed |Added CC||quantheory at gmail dot com --- Comment #10 from Sean Santos --- If it should be an error to specify both a shape spec and a source array, then that's something that's only come up with this bug. Everything else is probably a duplicate of PR 44672 or PR 44529. However, you have to be careful, since it is legal to specify a shape spec and a source scalar, e.g.: integer, allocatable :: a(:) integer :: b = 2 allocate(a(3), source=b) print *,a end
[Bug fortran/45440] [F03] ALLOCATE with SOURCE gives an ICE (segfault)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440 --- Comment #9 from Dominique d'Humieres 2013-01-08 12:34:01 UTC --- It looks like a duplicate of pr44672.
[Bug fortran/45440] [F03] ALLOCATE with SOURCE gives an ICE (segfault)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440
--- Comment #8 from Dominique d'Humieres 2012-09-22
21:57:52 UTC ---
If I apply the following patch
--- ../_clean/gcc/fortran/resolve.c2012-09-17 15:50:08.0 +0200
+++ gcc/fortran/resolve.c2012-09-22 18:02:47.0 +0200
@@ -7051,10 +7053,15 @@ conformable_arrays (gfc_expr *e1, gfc_ex
mpz_sub (s, s, tail->u.ar.start[i]->value.integer);
mpz_add_ui (s, s, 1);
}
- else
+ else if(tail->u.ar.start[i])
{
mpz_set (s, tail->u.ar.start[i]->value.integer);
}
+ else
+{
+ gcc_unreachable ();
+ /* mpz_set (s, e1->shape[i]); */
+}
if (mpz_cmp (e1->shape[i], s) != 0)
{
the segmentation fault is indeed replaced with
f951: internal compiler error: in conformable_arrays, at fortran/resolve.c:7062
which means that the allocatable corresponding to tail should be "decorated"
(bounds, size, ...) somewhere (in a way similar to the lhs reallocation on
assignment).
Also the new else if block seems weird in two counts:
(1) I do not see how it can be reached (I tried something such as b(3:), but I
got a syntax error earlier).
(2) I does not make sense for me to compare tail->u.ar.start[i] to
e1->shape[i].
[Bug fortran/45440] [F03] ALLOCATE with SOURCE gives an ICE (segfault)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440 --- Comment #7 from Dominique d'Humieres 2012-09-22 12:37:41 UTC --- *** Bug 47616 has been marked as a duplicate of this bug. ***
[Bug fortran/45440] [F03] ALLOCATE with SOURCE gives an ICE (segfault)
--- Comment #6 from janus at gcc dot gnu dot org 2010-08-29 17:22 --- cf. PR 44529 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440
[Bug fortran/45440] [F03] ALLOCATE with SOURCE gives an ICE (segfault)
--- Comment #5 from burnus at gcc dot gnu dot org 2010-08-28 14:05 ---
(In reply to comment #4)
> It works though when explicitly specifying the size of z to allocate:
>
> logical, allocatable :: z(:)
> allocate ( z(3), source = [ .true., .false., .true. ] )
Congratulation - you have found another bug:
"C633 (R631) If allocate-object is an array either allocate-shape-spec-list
shall appear or source-expr shall appear [...]"
In your example both appear. ("source-expr" is either SOURCE= or MOLD=.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440
[Bug fortran/45440] [F03] ALLOCATE with SOURCE gives an ICE (segfault)
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-28 11:55 --- It works though when explicitly specifying the size of z to allocate: logical, allocatable :: z(:) allocate ( z(3), source = [ .true., .false., .true. ] ) print *, z end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440
[Bug fortran/45440] [F03] ALLOCATE with SOURCE gives an ICE (segfault)
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-28 11:51 --- The following variant segfaults as well (same backtrace): logical, allocatable :: z(:) logical, dimension(1:3) :: src = (/ .true., .false., .true. /) allocate ( z, source = src) print *, z end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440
[Bug fortran/45440] [F03] ALLOCATE with SOURCE gives an ICE (segfault)
--- Comment #2 from janus at gcc dot gnu dot org 2010-08-28 11:46 --- valgrind says: ==29743== Invalid read of size 4 ==29743==at 0x52B37DB: __gmpz_set (in /usr/lib/libgmp.so.3.5.2) ==29743==by 0x532C37: conformable_arrays (resolve.c:6525) ==29743==by 0x533175: resolve_allocate_expr (resolve.c:6679) ==29743==by 0x533EA6: resolve_allocate_deallocate (resolve.c:6990) ==29743==by 0x537AB4: resolve_code (resolve.c:9017) ==29743==by 0x541422: resolve_codes (resolve.c:13320) ==29743==by 0x54151D: gfc_resolve (resolve.c:13347) ==29743==by 0x51E86A: resolve_all_program_units (parse.c:4187) ==29743==by 0x51EEE5: gfc_parse_file (parse.c:4416) ==29743==by 0x562C6E: gfc_be_parse_file (f95-lang.c:241) ==29743==by 0xA35DA8: compile_file (toplev.c:971) ==29743==by 0xA38051: do_compile (toplev.c:2321) ==29743== Address 0x7c is not stack'd, malloc'd or (recently) free'd -- janus at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org Known to fail||4.5.2 4.6.0 Summary|ALLOCATE with SOURCE gives |[F03] ALLOCATE with SOURCE |an ICE (segfault) |gives an ICE (segfault) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440
