public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Harald Anlauf <anlauf@gmx.de>
To: Tobias Burnus <tobias@codesourcery.com>,
	gcc-patches <gcc-patches@gcc.gnu.org>,
	fortran <fortran@gcc.gnu.org>
Subject: Re: [Patch, Fortran] libgfortran's ISO_Fortran_binding.c: Use GCC11 version for backward-only code [PR108056]
Date: Wed, 14 Dec 2022 20:26:30 +0100	[thread overview]
Message-ID: <6b3f24aa-efff-b462-0c5f-26772cfd462a@gmx.de> (raw)
In-Reply-To: <86a8d0f0-e3e3-3abe-f024-149615d2af4b@codesourcery.com>

Hi Tobias,

thanks for your explanation!  Now things are clearer.

Am 14.12.22 um 08:57 schrieb Tobias Burnus:
>>> @@ -63 +66 @@ cfi_desc_to_gfc_desc (gfc_array_void *d,
>>> -  d->dtype.version = s->version;
>>> +  d->dtype.version = 0;
>>
>> I was wondering what the significance of "version" is.
>> In ISO_Fortran_binding.h we seem to always have
>>    #define CFI_VERSION 1
>> and it did not change with gcc-12.
>
> The version is 1 for CFI but it is 0 for GFC. However, as we do not
> check the GFC version anywhere and it is not publicly exposed, it does
> not really matter. Still, "d->dtype.version = 0;" matches what the
> compiler itself produces – and for consistency, setting it to 0 is
> better than setting it to 1 (via CFI's version field).
>
> Actually 'dtype.version' is not really set anywhere; at least
> gfc_get_dtype_rank_type(...) does not set it; zero initialization is
> most common but it could be also some random value. In libgfortran,
> GFC_DTYPE_CLEAR explicitly sets it to 0.

OK, that was not easy to find.

>>> @@ -107 +117 @@ gfc_desc_to_cfi_desc (CFI_cdesc_t **d_pt
>>> -  d->version = s->dtype.version;
>>> +  d->version = CFI_VERSION;
>>
>> This treatment of "version" was the equivalent to the above that
>> confused me.  Assuming we were to change CFI_VERSION in gcc-13+,
>> is this the right choice here regarding backward compatibility?
>
> I don't think we will change CFI version any time soon as we rather
> closely follow the Fortran standard and I do not see any changes which
> are required there.
>
> NOTE: As s->dtype.version is either 0 or some random value, setting
> version in the CFI / ISO C descriptor to 1, be it as literal or as macro
> constant, makes it the same as CFI_VERSION.

OK

> And: I don't think we will change CFI_VERSION or the structure of the
> CFI array descriptor any time soon; there does not seem to be any need
> for it, it matches the Fortran standard one well (and no plans seem to
> be planed on that side) and, finally, changing an array descriptor is
> painful!

Agreed.

> However, using '1;  /* CFI_VERSION in GCC 11 and at time of writing. */'
> would also work – but I would expect that we will go through all CFI
> users if we ever change the descriptor (and bump the version), possibly
> adding version-number dependent code.

Agreed.  Searching for a string that can be guessed is
easier that looking for a magic '1'.

>> So besides the "version" question ok from my side.
>
> I hope I could answer the latter.

Yes, and thanks for the patch!

Harald

> Tobias
>
> -----------------
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201,
> 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer:
> Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München;
> Registergericht München, HRB 106955
>


  reply	other threads:[~2022-12-14 19:26 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-13 16:29 Tobias Burnus
2022-12-13 20:53 ` Harald Anlauf
2022-12-13 21:41   ` Tobias Burnus
2022-12-13 22:27     ` Harald Anlauf
2022-12-14  7:57       ` Tobias Burnus
2022-12-14 19:26         ` Harald Anlauf [this message]
2022-12-14  8:21 ` 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=6b3f24aa-efff-b462-0c5f-26772cfd462a@gmx.de \
    --to=anlauf@gmx.de \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=tobias@codesourcery.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).