public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andre Vehreschild <vehre@gmx.de>
To: Paul Richard Thomas <paul.richard.thomas@gmail.com>
Cc: GCC-Patches-ML <gcc-patches@gcc.gnu.org>,
	GCC-Fortran-ML <fortran@gcc.gnu.org>
Subject: Re: [Patch, fortran, pr67451, v1] [5/6 Regression] ICE with sourced allocation from coarray
Date: Wed, 10 Feb 2016 11:26:00 -0000	[thread overview]
Message-ID: <20160210122624.2114b57d@vepi2> (raw)
In-Reply-To: <CAGkQGiJoXZZXQbr8C_4DhjRXryjFLosNGmMo2GXe3eHwyPk_tw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]

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 

[-- Attachment #2: pr67451_v6_2.patch --]
[-- Type: text/x-patch, Size: 3342 bytes --]

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" } }

[-- Attachment #3: pr67451_v6_2.txt --]
[-- Type: text/plain, Size: 371 bytes --]

gcc/testsuite/ChangeLog:

2016-02-10  Andre Vehreschild  <vehre@gcc.gnu.org>

	PR fortran/67451
	* gfortran.dg/coarray_allocate_5.f08: New test.


gcc/fortran/ChangeLog:

2016-02-10  Andre Vehreschild  <vehre@gcc.gnu.org>

	PR fortran/67451
	* trans-array.c (gfc_array_allocate): Take the attributes from the
	expression to allocate and not from the source=-expression.


  reply	other threads:[~2016-02-10 11:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-29 18:17 Andre Vehreschild
2016-02-01 12:20 ` [Patch, fortran, pr67451, gcc-5, " Andre Vehreschild
2016-02-01 12:35   ` Andre Vehreschild
2016-02-02 18:44     ` Paul Richard Thomas
2016-02-03 10:39       ` Andre Vehreschild
2016-02-02 18:24 ` [Patch, fortran, pr67451, " Paul Richard Thomas
2016-02-10 11:26   ` Andre Vehreschild [this message]
2016-02-17  9:17     ` [PING, Patch, " Andre Vehreschild
2016-02-17 13:13     ` [Patch, " Paul Richard Thomas
2016-02-23 10:30       ` Andre Vehreschild
2016-02-10 16:48 Dominique d'Humières

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160210122624.2114b57d@vepi2 \
    --to=vehre@gmx.de \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=paul.richard.thomas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).