public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Harald Anlauf <anlauf@gmx.de>
To: gcc-patches@gcc.gnu.org
Cc: fortran@gcc.gnu.org
Subject: Re: [PATCH] Fortran: fix passing array component to polymorphic argument [PR105658]
Date: Mon, 19 Feb 2024 20:52:14 +0100	[thread overview]
Message-ID: <612abd9a-389e-4eab-b1fb-30b22cdaf8ba@gmx.de> (raw)
Message-ID: <20240219195214.JdmTpKdfR4LwKOro_QYwLxiFT4qspiRWbB1CYEz6WrM@z> (raw)
In-Reply-To: <CAFmps25O9KUejAcp2R5adbynfq-KhGg8VSQmqzFWsSt8dBTvDg@mail.gmail.com>

Hi Peter,

On 2/19/24 16:19, Peter Hill wrote:
> Hi Harald,
> 
> Thanks for your help, please see the updated and signed-off patch below.

great!  This is fine, and I'll commit it tomorrow unless others
have further comments.

> It also occurred to me that array temporaries aren't _required_ here
> (for arrays of derived type components), but in the general case with
> a type with differently sized components, the stride wouldn't be a
> multiple of the component's type's size. Is it possible in principle
> to have an arbitrary stride?

It is possible to have an arbitrary (fixed, non-unit) stride,
but it is not always taken advantage of.

If you take the last version of the testcase and compile with
option -fdump-tree-original, you can see that the cases commented
with "no temp needed" actually create a suitable descriptor.
E.g.

     call print_poly (uu(2,2::2))

becomes:

     {
       struct __class__STAR_1_0t class.28;
       struct array01_integer(kind=4) parm.29;

       class.28._vptr = (struct __vtype__STAR * {ref-all}) 
&__vtab_INTEGER_4_;
       parm.29.span = 4;
       parm.29.dtype = {.elem_len=4, .version=0, .rank=1, .type=1};
       parm.29.dim[0].lbound = 1;
       parm.29.dim[0].ubound = 3;
       parm.29.dim[0].stride = 10;
       parm.29.data = (void *) &uu[6];
       parm.29.offset = -10;
       class.28._data = parm.29;
       class.28._len = 0;
       print_poly (&class.28);
     }

Since we know that 'uu' is a contiguous array, we can calculate
the stride (10) for the 1-d section.

The case of the section of the character array is quite similar,
but the variant with the substring reference would need further
work to avoid the temporary.  (It would be possible.)

But as you say, the general case, which may involve types/classes,
does not map to a simple descriptor.

Thanks for your patch!

Harald



  reply	other threads:[~2024-02-19 19:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-15 17:50 Peter Hill
2024-02-16 21:19 ` Harald Anlauf
2024-02-16 21:19   ` Harald Anlauf
2024-02-19 15:19   ` Peter Hill
2024-02-19 19:52     ` Harald Anlauf [this message]
2024-02-19 19:52       ` Harald Anlauf
2024-02-20 19:53     ` Harald Anlauf
2024-02-20 19:53       ` Harald Anlauf
2024-02-20 20:09       ` Steve Kargl

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=612abd9a-389e-4eab-b1fb-30b22cdaf8ba@gmx.de \
    --to=anlauf@gmx.de \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    /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).