public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <rguenther@suse.de>
To: Eric Botcazou <ebotcazou@adacore.com>
Cc: gcc-patches@gcc.gnu.org, jason@redhat.com, fortran@gcc.gnu.org
Subject: Re: [PATCH] Fix type field walking in gimplifier unsharing
Date: Thu, 28 Apr 2016 12:10:00 -0000	[thread overview]
Message-ID: <alpine.LSU.2.11.1604281408350.13384@t29.fhfr.qr> (raw)
In-Reply-To: <alpine.LSU.2.11.1604281249090.13384@t29.fhfr.qr>

On Thu, 28 Apr 2016, Richard Biener wrote:

> On Thu, 28 Apr 2016, Eric Botcazou wrote:
> 
> > > Aww, I was hoping for sth that would not require me to fix all
> > > frontends ...
> > 
> > I don't really see how this can work without DECL_EXPR though.  You need to 
> > define when the variable-sized expressions are evaluated to lay out the type, 
> > otherwise it will be laid out on the first use, which may see a different 
> > value of the expressions than the definition point.  The only way to do that 
> > for a locally-defined type is to add a DECL_EXPR in GENERIC, so that the 
> > gimplifier evaluates the expressions at the right spot.
> 
> Ah, so the C++ FE does this correctly but in addition to that it has
> 
>           /* When the pointed-to type involves components of variable 
> size,
>              care must be taken to ensure that the size evaluation code is
>              emitted early enough to dominate all the possible later uses
>              and late enough for the variables on which it depends to have
>              been assigned.
> 
>              This is expected to happen automatically when the pointed-to
>              type has a name/declaration of it's own, but special 
> attention
>              is required if the type is anonymous.
> ...
>           if (!TYPE_NAME (type)
>               && (decl_context == NORMAL || decl_context == FIELD)
>               && at_function_scope_p ()
>               && variably_modified_type_p (type, NULL_TREE))
>             /* Force evaluation of the SAVE_EXPR.  */
>             finish_expr_stmt (TYPE_SIZE (type));
> 
> so in this case the type doesn't have an associated TYPE_DECL and thus
> we can't build a DECL_EXPR.  To me the correct fix is then to
> always force a TYPE_DECL for variable-modified types.
> 
> Jason?

The following works (for the testcase):

Index: gcc/cp/decl.c
===================================================================
--- gcc/cp/decl.c       (revision 235547)
+++ gcc/cp/decl.c       (working copy)
@@ -10393,8 +10393,11 @@ grokdeclarator (const cp_declarator *dec
              && (decl_context == NORMAL || decl_context == FIELD)
              && at_function_scope_p ()
              && variably_modified_type_p (type, NULL_TREE))
-           /* Force evaluation of the SAVE_EXPR.  */
-           finish_expr_stmt (TYPE_SIZE (type));
+           {
+             TYPE_NAME (type) = build_decl (UNKNOWN_LOCATION, TYPE_DECL,
+                                            NULL_TREE, type);
+             add_decl_expr (TYPE_NAME (type));
+           }
 
          if (declarator->kind == cdk_reference)
            {

and I have a similar fix for the Fortran FE for one testcase I
reduced to

  character(10), dimension (2) :: implicit_result
  character(10), dimension (2) :: source
  implicit_result = reallocate_hnv (LEN (source))
contains
  FUNCTION reallocate_hnv(LEN)
    CHARACTER(LEN=LEN), DIMENSION(:), POINTER :: reallocate_hnv
  END FUNCTION reallocate_hnv
end

Index: fortran/trans-array.c
===================================================================
--- fortran/trans-array.c       (revision 235547)
+++ fortran/trans-array.c       (working copy)
@@ -1094,6 +1094,16 @@ gfc_trans_create_temp_array (stmtblock_t
   info->descriptor = desc;
   size = gfc_index_one_node;
 
+  /* Emit a DECL_EXPR for the variable sized array type in
+     GFC_TYPE_ARRAY_DATAPTR_TYPE so the gimplification of its type
+     sizes works correctly.  */
+  tree arraytype = TREE_TYPE (GFC_TYPE_ARRAY_DATAPTR_TYPE (type));
+  if (! TYPE_NAME (arraytype))
+    TYPE_NAME (arraytype) = build_decl (UNKNOWN_LOCATION, TYPE_DECL,
+                                       NULL_TREE, arraytype);
+  gfc_add_expr_to_block (pre, build1 (DECL_EXPR,
+                                     arraytype, TYPE_NAME (arraytype)));
+
   /* Fill in the array dtype.  */
   tmp = gfc_conv_descriptor_dtype (desc);
   gfc_add_modify (pre, tmp, gfc_get_dtype (TREE_TYPE (desc)));


I wonder if we can avoid allocating the TYPE_DECL by simply also
allowing TREE_TYPE as operand of a DECL_EXPR (to avoid adding
a 'TYPE_EXPR').

Richard.

  reply	other threads:[~2016-04-28 12:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-27  8:49 Richard Biener
2016-04-27  9:16 ` Eric Botcazou
2016-04-27 10:29   ` Richard Biener
2016-04-28 10:22     ` Eric Botcazou
2016-04-28 10:53       ` Richard Biener
2016-04-28 12:10         ` Richard Biener [this message]
2016-04-29  8:15           ` Eric Botcazou
2016-04-29  8:18             ` Richard Biener

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=alpine.LSU.2.11.1604281408350.13384@t29.fhfr.qr \
    --to=rguenther@suse.de \
    --cc=ebotcazou@adacore.com \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.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).