public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Thomas Koenig <tkoenig@netcologne.de>
To: Janne Blomqvist <blomqvist.janne@gmail.com>
Cc: "fortran@gcc.gnu.org" <fortran@gcc.gnu.org>,
	gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [patch, libfortran] Use flexible array members for array descriptor
Date: Mon, 05 Feb 2018 20:53:00 -0000	[thread overview]
Message-ID: <5e442836-8c4c-8df6-07ad-abcffd86dd23@netcologne.de> (raw)
In-Reply-To: <CAO9iq9Fon+qQw8wz4BbBwASv-ohoVRbuWzQR+gh7bGf4XVXcBQ@mail.gmail.com>

Am 05.02.2018 um 13:09 schrieb Janne Blomqvist:
> On Sun, Feb 4, 2018 at 9:49 PM, Thomas Koenig <tkoenig@netcologne.de> wrote:
>> Hello world,
>>
>> in the attached patch, I have used flexible array members for
>> using the different descriptor types (following Richi's advice).
>> This does not change the binary ABI, but the library code
>> maches what we are actually doing in the front end.  I have
>> not yet given up hope of enabling LTO for the library :-)
>> and this, I think, will be a prerequisite.
>>
>> OK for trunk?
> 
> Given that Jakub and Richi apparently weren't yet unanimous in their
> recommendations on the best path forward, maybe wait a bit for the
> smoke to clear?

Make sense.  Depending on what the solution is, this (or a variant)
will probably part of the patch.

> In the meantime, a few comments:
> 
> 1) Is there some particular benefit to all those macroized
> descriptors, given that the only thing different is the type of the
> base_addr pointer? Wouldn't it be simpler to just have a single
> descriptor type with base_addr a void pointer, then typecast that
> pointer to whatever type is needed?

I don't particulary like going through void* pointers - it is
clearer to leave an int* as an int*.

> 2)
> 
> Index: intrinsics/date_and_time.c
> ===================================================================
> --- intrinsics/date_and_time.c (Revision 257347)
> +++ intrinsics/date_and_time.c (Arbeitskopie)
> @@ -268,7 +268,7 @@ secnds (GFC_REAL_4 *x)
>     GFC_REAL_4 temp1, temp2;
> 
>     /* Make the INTEGER*4 array for passing to date_and_time.  */
> -  gfc_array_i4 *avalues = xmalloc (sizeof (gfc_array_i4));
> +  gfc_array_i4 *avalues = xmalloc (sizeof (gfc_full_array_i4));
> 
> 
> Since date_and_time requires the values array to always be rank 1,
> can't this be "xmalloc (sizeof (gfc_array_i4) +
> sizeof(dimension_data))" ?

I think we can be fairly sure that this would be OK at the moment, since
(I think) there are no gaps in our descriptors at the moment. Anybody
invents an architecture where this is not the case, we introduce
a bug. This way is safer.

Regards

	Thomas

  reply	other threads:[~2018-02-05 20:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-04 19:49 Thomas Koenig
2018-02-05 12:09 ` Janne Blomqvist
2018-02-05 20:53   ` Thomas Koenig [this message]
2018-02-06  8:53     ` Janne Blomqvist
2018-02-06 22:28       ` Thomas Koenig
2018-02-08 11:27   ` Richard Biener
2018-02-12 19:42     ` Thomas Koenig
2018-02-12 19:47       ` Janne Blomqvist
2018-02-12 20:10       ` Jakub Jelinek
2018-02-12 21:50         ` Thomas Koenig

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=5e442836-8c4c-8df6-07ad-abcffd86dd23@netcologne.de \
    --to=tkoenig@netcologne.de \
    --cc=blomqvist.janne@gmail.com \
    --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).