Message ID | 20160210122624.2114b57d@vepi2 |
---|---|
State | New |
Headers | show |
PING ! On Wed, 10 Feb 2016 12:26:24 +0100 Andre Vehreschild <vehre@gmx.de> wrote: > Hi all, > > unfortunately was my last patch for pr67451 not perfect and introduced > regressions occurring on s390(x) and with the sanitizer. These were > caused, because when taking the array specs from the source=-expression > also its attributes, like coarray state and so on where taken from > there. This additionally added a corank to local objects to allocate, > that were no coarrays overwriting data in the array handle. The attached > patch fixes both issues. > > The patch for gcc-5 is not affected, because in gcc-5 the feature of > taking the array spec from the source=-expression is not implemented. > > Bootstrapped and regtested ok on x86_64-linux-gnu/F23. > > Ok for trunk? > > Regards, > Andre > > On Tue, 2 Feb 2016 19:24:46 +0100 > Paul Richard Thomas <paul.richard.thomas@gmail.com> wrote: > > > Hi Andre, > > > > This looks to be OK for trunk. > > > > I'll move to the 5-branch patch right away. > > > > Thanks > > > > Paul > > > > On 29 January 2016 at 19:17, Andre Vehreschild <vehre@gmx.de> wrote: > > > Hi all, > > > > > > attached is a patch to fix a regression in current gfortran when a > > > coarray is used in the source=-expression of an allocate(). The ICE was > > > caused by the class information, i.e., _vptr and so on, not at the > > > expected place. The patch fixes this. > > > > > > The patch also fixes pr69418, which I will flag as a duplicate in a > > > second. > > > > > > Bootstrapped and regtested ok on x86_64-linux-gnu/F23. > > > > > > Ok for trunk? > > > > > > Backport to gcc-5 is pending, albeit more difficult, because the > > > allocate() implementation on 5 is not as advanced the one in 6. > > > > > > Regards, > > > Andre > > > -- > > > Andre Vehreschild * Email: vehre ad gmx dot de > > > > > > > >
Dear Andre, I had left this to somebody else, since I am travelling! The patch is verging on 'obvious' and so it is OK for trunk. Could you check the line terminators please? I am seeing CR-LFs but this might be an effect of transmission. Thanks for the patch. Paul On 10 February 2016 at 12:26, Andre Vehreschild <vehre@gmx.de> wrote: > Hi all, > > unfortunately was my last patch for pr67451 not perfect and introduced > regressions occurring on s390(x) and with the sanitizer. These were > caused, because when taking the array specs from the source=-expression > also its attributes, like coarray state and so on where taken from > there. This additionally added a corank to local objects to allocate, > that were no coarrays overwriting data in the array handle. The attached > patch fixes both issues. > > The patch for gcc-5 is not affected, because in gcc-5 the feature of > taking the array spec from the source=-expression is not implemented. > > Bootstrapped and regtested ok on x86_64-linux-gnu/F23. > > Ok for trunk? > > Regards, > Andre > > On Tue, 2 Feb 2016 19:24:46 +0100 > Paul Richard Thomas <paul.richard.thomas@gmail.com> wrote: > >> Hi Andre, >> >> This looks to be OK for trunk. >> >> I'll move to the 5-branch patch right away. >> >> Thanks >> >> Paul >> >> On 29 January 2016 at 19:17, Andre Vehreschild <vehre@gmx.de> wrote: >> > Hi all, >> > >> > attached is a patch to fix a regression in current gfortran when a >> > coarray is used in the source=-expression of an allocate(). The ICE was >> > caused by the class information, i.e., _vptr and so on, not at the >> > expected place. The patch fixes this. >> > >> > The patch also fixes pr69418, which I will flag as a duplicate in a >> > second. >> > >> > Bootstrapped and regtested ok on x86_64-linux-gnu/F23. >> > >> > Ok for trunk? >> > >> > Backport to gcc-5 is pending, albeit more difficult, because the >> > allocate() implementation on 5 is not as advanced the one in 6. >> > >> > Regards, >> > Andre >> > -- >> > Andre Vehreschild * Email: vehre ad gmx dot de >> >> >> > > > -- > Andre Vehreschild * Email: vehre ad gmx dot de
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c index 2ff2833..649b80f 100644 --- a/gcc/fortran/trans-array.c +++ b/gcc/fortran/trans-array.c @@ -5401,17 +5401,8 @@ gfc_array_allocate (gfc_se * se, gfc_expr * expr, tree status, tree errmsg, if (!retrieve_last_ref (&ref, &prev_ref)) return false; - if (ref->u.ar.type == AR_FULL && expr3 != NULL) - { - /* F08:C633: Array shape from expr3. */ - ref = expr3->ref; - - /* Find the last reference in the chain. */ - if (!retrieve_last_ref (&ref, &prev_ref)) - return false; - alloc_w_e3_arr_spec = true; - } - + /* Take the allocatable and coarray properties solely from the expr-ref's + attributes and not from source=-expression. */ if (!prev_ref) { allocatable = expr->symtree->n.sym->attr.allocatable; @@ -5428,6 +5419,17 @@ gfc_array_allocate (gfc_se * se, gfc_expr * expr, tree status, tree errmsg, if (!dimension) gcc_assert (coarray); + if (ref->u.ar.type == AR_FULL && expr3 != NULL) + { + /* F08:C633: Array shape from expr3. */ + ref = expr3->ref; + + /* Find the last reference in the chain. */ + if (!retrieve_last_ref (&ref, &prev_ref)) + return false; + alloc_w_e3_arr_spec = true; + } + /* Figure out the size of the array. */ switch (ref->u.ar.type) { @@ -5463,7 +5465,8 @@ gfc_array_allocate (gfc_se * se, gfc_expr * expr, tree status, tree errmsg, gfc_init_block (&set_descriptor_block); size = gfc_array_init_size (se->expr, alloc_w_e3_arr_spec ? expr->rank : ref->u.ar.as->rank, - ref->u.ar.as->corank, &offset, lower, upper, + coarray ? ref->u.ar.as->corank : 0, + &offset, lower, upper, &se->pre, &set_descriptor_block, &overflow, expr3_elem_size, nelems, expr3, e3_arr_desc, e3_is_array_constr, expr); diff --git a/gcc/testsuite/gfortran.dg/coarray_allocate_5.f08 b/gcc/testsuite/gfortran.dg/coarray_allocate_5.f08 new file mode 100644 index 0000000..feb1bf3 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/coarray_allocate_5.f08 @@ -0,0 +1,32 @@ +! { dg-do run } +! { dg-options "-fcoarray=lib -lcaf_single -fdump-tree-original" } +! +! Contributed by Ian Harvey <ian_harvey@bigpond.com> +! Extended by Andre Vehreschild <vehre@gcc.gnu.org> +! to test that coarray references in allocate work now +! PR fortran/67451 + + program main + implicit none + type foo + integer :: bar = 99 + end type + class(foo), dimension(:), allocatable :: foobar[:] + class(foo), dimension(:), allocatable :: some_local_object + allocate(foobar(10)[*]) + + allocate(some_local_object, source=foobar) + + if (.not. allocated(foobar)) call abort() + if (lbound(foobar, 1) /= 1 .OR. ubound(foobar, 1) /= 10) call abort() + if (.not. allocated(some_local_object)) call abort() + if (any(some_local_object(:)%bar /= [99, 99, 99, 99, 99, 99, 99, 99, 99, 99])) call abort() + + deallocate(some_local_object) + deallocate(foobar) + end program + +! Check that some_local_object is treated as rank-1 array. +! This failed beforehand, because the coarray attribute of the source=expression +! was propagated to some_local_object in the allocate. +! { dg-final { scan-tree-dump-not "some_local_object\._data\.dim\[1\]\.lbound" "original" } }