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);
next prev parent 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).