From: Mikael Morin <mikael.morin@sfr.fr>
To: Andre Vehreschild <vehre@gmx.de>,
GCC-Patches-ML <gcc-patches@gcc.gnu.org>,
GCC-Fortran-ML <fortran@gcc.gnu.org>
Subject: Re: [Patch, fortran, PR44672, v6] [F08] ALLOCATE with SOURCE and no array-spec
Date: Mon, 25 May 2015 19:35:00 -0000 [thread overview]
Message-ID: <556369B1.8030600@sfr.fr> (raw)
In-Reply-To: <20150519122602.028db8d5@vepi2>
Le 19/05/2015 12:26, Andre Vehreschild a écrit :
> Hi all,
>
> update based on latest 65548 (v5) patch and current trunk. Description and
> issue addressed unchanged (see cite below).
>
> Bootstrapped and regtested on x86_64-linux-gnu/f21.
>
> Any volunteers to review? The initial version dates back to March 30. 2015. Not
> a single comment so far!
>
Let's start now. ;-)
I don't understand why one of your previous patches was factoring the
source expression evaluation to a temporary in gfc_trans_allocate, and
now with this patch you do the same thing in gfc_resolve_allocate, not
reusing the part in gfc_trans_allocate.
> *************** failure:
> *** 7201,7212 ****
> --- 7212,7229 ----
> return false;
> }
>
> +
> static void
> resolve_allocate_deallocate (gfc_code *code, const char *fcn)
> {
> gfc_expr *stat, *errmsg, *pe, *qe;
> gfc_alloc *a, *p, *q;
>
> + /* When this flag is set already, then this allocate has already been
> + resolved. Doing so again, would result in an endless loop. */
> + if (code->ext.alloc.arr_spec_from_expr3)
> + return;
> +
I expect you'll miss some error messages by doing this.
Where is the endless loop?
> *************** resolve_allocate_deallocate (gfc_code *c
> *** 7375,7382 ****
> --- 7392,7500 ----
>
> if (strcmp (fcn, "ALLOCATE") == 0)
> {
> + bool arr_alloc_wo_spec = false;
> for (a = code->ext.alloc.list; a; a = a->next)
> ! resolve_allocate_expr (a->expr, code, &arr_alloc_wo_spec);
> !
> ! if (arr_alloc_wo_spec && code->expr3)
> ! {
[...]
> !
> ! ass = gfc_get_code (EXEC_ASSIGN);
This memory is not freed as far as I know.
I think you can use a local variable for it.
*** /tmp/PRaWHc_trans-expr.c 2015-05-25 19:54:35.056309429 +0200
--- /tmp/7e82nd_trans-expr.c 2015-05-25 19:54:35.058309429 +0200
*************** gfc_conv_procedure_call (gfc_se * se, gf
*** 5328,5334 ****
if (e && (e->ts.type == BT_DERIVED || e->ts.type == BT_CLASS)
&& e->ts.u.derived->attr.alloc_comp
&& !(e->symtree && e->symtree->n.sym->attr.pointer)
! && (e->expr_type != EXPR_VARIABLE && !e->rank))
{
int parm_rank;
tmp = build_fold_indirect_ref_loc (input_location,
--- 5328,5335 ----
if (e && (e->ts.type == BT_DERIVED || e->ts.type == BT_CLASS)
&& e->ts.u.derived->attr.alloc_comp
&& !(e->symtree && e->symtree->n.sym->attr.pointer)
! && e->expr_type != EXPR_VARIABLE && !e->rank
! && e->expr_type != EXPR_STRUCTURE)
{
int parm_rank;
tmp = build_fold_indirect_ref_loc (input_location,
Can't you remove this? It's undone by the PR58586 patch.
> *************** gfc_trans_allocate (gfc_code * code)
> *** 5733,5746 ****
>
> if (dataref && dataref->u.c.component->as)
> {
> ! int dim;
> gfc_expr *temp;
> gfc_ref *ref = dataref->next;
> ref->u.ar.type = AR_SECTION;
> /* We have to set up the array reference to give ranges
> in all dimensions and ensure that the end and stride
> are set so that the copy can be scalarized. */
> - dim = 0;
> for (; dim < dataref->u.c.component->as->rank; dim++)
> {
> ref->u.ar.dimen_type[dim] = DIMEN_RANGE;
> --- 5758,5815 ----
>
> if (dataref && dataref->u.c.component->as)
> {
> ! int dim = 0;
> gfc_expr *temp;
> gfc_ref *ref = dataref->next;
> ref->u.ar.type = AR_SECTION;
> + if (code->ext.alloc.arr_spec_from_expr3)
> + {
> + /* Take the array dimensions from the
> + source=-expression. */
> + gfc_array_ref *source_ref =
> + gfc_find_array_ref (code->expr3);
Does this work? code->expr3 is not always a variable.
> + if (source_ref->type == AR_FULL)
> + {
> + /* For full array refs copy the bounds. */
> + for (; dim < dataref->u.c.component->as->rank; dim++)
> + {
> + ref->u.ar.dimen_type[dim] = DIMEN_RANGE;
> + ref->u.ar.start[dim] =
> + gfc_copy_expr (source_ref->as->lower[dim]);
> + ref->u.ar.end[dim] =
> + gfc_copy_expr (source_ref->as->upper[dim]);
> + }
This won't work. Consider this:
block
integer :: a(n)
n = n+1
allocate(b, source=a)
end block
You have to use a full array ref. In fact you can use a full array ref
everywhere, I think.
That's all for now.
Mikael
next prev parent reply other threads:[~2015-05-25 18:28 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-30 17:48 [Patch, fortran, PR44672, v1] " Andre Vehreschild
2015-04-01 13:15 ` [Patch, fortran, PR44672, v2] " Andre Vehreschild
2015-04-02 9:03 ` [Patch, fortran, PR44672, v3] " Andre Vehreschild
2015-04-23 12:45 ` [Ping, Patch, " Andre Vehreschild
2015-04-29 15:29 ` [Patch, fortran, PR44672, v4] " Andre Vehreschild
2015-04-30 14:31 ` [Patch, fortran, PR44672, v5] " Andre Vehreschild
2015-05-19 10:29 ` [Patch, fortran, PR44672, v6] " Andre Vehreschild
2015-05-22 10:24 ` Ping: " Andre Vehreschild
2015-05-25 19:35 ` Mikael Morin [this message]
2015-05-28 15:48 ` Andre Vehreschild
2015-05-28 18:42 ` Mikael Morin
2015-05-29 12:41 ` Andre Vehreschild
2015-05-30 4:23 ` Thomas Koenig
2015-06-02 16:52 ` Mikael Morin
2015-06-03 15:25 ` Andre Vehreschild
2015-06-05 12:04 ` [Patch, fortran, PR44672, v9] " Andre Vehreschild
2015-06-09 5:36 ` Damian Rouson
2015-06-10 8:59 ` [Patch, fortran, PR44672, v10] " Andre Vehreschild
2015-06-11 22:05 ` Thomas Koenig
2015-06-12 8:00 ` Andre Vehreschild
2015-06-15 10:43 ` 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=556369B1.8030600@sfr.fr \
--to=mikael.morin@sfr.fr \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=vehre@gmx.de \
/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).