public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andre Vehreschild <vehre@gmx.de>
To: Mikael Morin <mikael.morin@sfr.fr>
Cc: GCC-Patches-ML <gcc-patches@gcc.gnu.org>,
	GCC-Fortran-ML <fortran@gcc.gnu.org>
Subject: Re: [Patch, Fortran, PR58586, v3]  ICE with derived type with allocatable component passed by value
Date: Fri, 08 May 2015 14:11:00 -0000	[thread overview]
Message-ID: <20150508161111.33be9f14@gmx.de> (raw)
In-Reply-To: <20150508153146.75933da8@gmx.de>

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

Hi,

so attached is a quick and dirty solution for the allocatable return value
problem. I personally don't like it. It is making a special case from the
assign a function result to a variable. May be you have a better idea how to do
this in gfortran style.

- Andre


On Fri, 8 May 2015 15:31:46 +0200
Andre Vehreschild <vehre@gmx.de> wrote:

> Hi Mikael,
> 
> > > ?? I don't get you there? What do you mean? Do you think the
> > > alloc_comp_class_3/4.* are not correctly testing the issue? Any idea of
> > > how to test this better? I mean the pr is about this artificial
> > > constructs. I merely struck it in search of a pr about allocatable
> > > components. 
> > 
> > I was talking about the bug you found with t_init above.  :-)
> > the compiler is not ready to accept that function in a testcase.
> > The alloc_omp_class_3/4 are fine.
> 
> Oh, sorry, I misunderstood you there. Now let's see, where that one is hiding.
> 
> - Andre


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

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

diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 402d9b9..87e2cde 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -9043,6 +9043,7 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr * expr2, bool init_flag,
   stmtblock_t body;
   bool l_is_temp;
   bool scalar_to_array;
+  bool alloc_to_alloc;
   tree string_length;
   int n;
 
@@ -9156,6 +9157,18 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr * expr2, bool init_flag,
   else
     gfc_conv_expr (&lse, expr1);
 
+  alloc_to_alloc = expr1->expr_type == EXPR_VARIABLE
+      && expr1->symtree->n.sym->ts.type == BT_DERIVED
+      && expr1->symtree->n.sym->attr.allocatable
+      && expr2->expr_type == EXPR_FUNCTION
+      && expr2->ts.type == BT_DERIVED
+      && expr2->value.function.esym->attr.allocatable;
+  if (alloc_to_alloc)
+    {
+      rse.expr = gfc_build_addr_expr (NULL_TREE, rse.expr);
+      lse.expr = gfc_build_addr_expr (NULL_TREE, lse.expr);;
+    }
+
   /* Assignments of scalar derived types with allocatable components
      to arrays must be done with a deep copy and the rhs temporary
      must have its components deallocated afterwards.  */
@@ -9208,7 +9221,8 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr * expr2, bool init_flag,
   if (lss == gfc_ss_terminator)
     {
       /* F2003: Add the code for reallocation on assignment.  */
-      if (flag_realloc_lhs && is_scalar_reallocatable_lhs (expr1))
+      if (flag_realloc_lhs && !alloc_to_alloc
+	  && is_scalar_reallocatable_lhs (expr1))
 	alloc_scalar_allocatable_for_assignment (&block, string_length,
 						 expr1, expr2);
 

  reply	other threads:[~2015-05-08 14:11 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-15 18:03 [Patch, Fortran, PR58586, v1] " Andre Vehreschild
2015-04-19 10:01 ` Mikael Morin
2015-04-23 18:01   ` [Patch, Fortran, PR58586, v2] " Andre Vehreschild
2015-04-24  8:37     ` Andre Vehreschild
2015-04-26 10:23     ` Mikael Morin
2015-05-05  9:00       ` [Patch, Fortran, PR58586, v3] " Andre Vehreschild
2015-05-07 10:15         ` Mikael Morin
2015-05-08 10:54           ` Andre Vehreschild
2015-05-08 13:21             ` Mikael Morin
2015-05-08 13:31               ` Andre Vehreschild
2015-05-08 14:11                 ` Andre Vehreschild [this message]
2015-05-19 14:02                   ` [Patch, Fortran, PR58586, v4] " Andre Vehreschild
2015-07-03  9:29                     ` [Ping, Patch, Fortran, PR58586, v5] " Andre Vehreschild
2015-07-04 16:25                       ` Steve Kargl
2015-07-04 19:20                         ` Andre Vehreschild
2015-07-05 16:15                           ` Steve Kargl
2015-07-05 17:48                             ` Paul Richard Thomas
2015-07-05 18:14                               ` Steve Kargl
2015-07-06 10:32                               ` [commited, " Andre Vehreschild

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=20150508161111.33be9f14@gmx.de \
    --to=vehre@gmx.de \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=mikael.morin@sfr.fr \
    /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).