public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/103496] [F2018][TS29113] C_SIZEOF – rejects now valid args with 'must be an interoperable data entity'
Date: Tue, 30 Nov 2021 21:02:57 +0000	[thread overview]
Message-ID: <bug-103496-4-v3U1mTtBFH@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-103496-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103496

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to anlauf from comment #1)
> https://j3-fortran.org/doc/year/21/21-134r2.txt
> but it still requires using interoperable types etc.
> Just asking: did you simply forget to "decorate" your declarations?

If you talk about something like 'kind=c_int': On most systems, c_int ==
c_int32_t == 4 - and gfortran has (by default) a default integer == 4. But also
'kind=8' is very likely to be interoperable; whether it is with c_long or only
c_int64_t or ... does not really matter in case of c_sizeof – we just need to
know that some C type exists, which is interoperable.
[Likewise,  integer(kind=c_int128_t)  may or may not be interoperable,
depending whether that kind is available - and if not, c_int128_t should be a
negative number. (Ignoring for now that c_int128_t is a vendor extension.)]

But granted, usually you want to be sure that kind matches a specific C integer
type and then c_... becomes useful and more portable.

 * * *

'interoperable type': I have to admit that I tend to get confused whether
* "18.3.5 Interoperability of array variables"
applies or whether also
* "18.3.6 Interoperability of procedures and procedure interfaces"
applies. In the latter case, array descriptors are permitted - and that permits
allocatables, pointer, sub-sections etc. The former is more restrictive by only
permitting explicit shape or assumed size – while the latter permits more.

Given that the current wording for c_sizeof is about "that is not an
assumed-size array or an assumed-rank array that is associated with an
assumed-size array."
I think one reasonable reading is that 18.3.6 applies as 18.3.5 does not permit
assumed rank.

As 21-134r2 shows, the current wording is not ideal – but at the end, the
modification just implies that 18.3.5 applies (IMHO).

  parent reply	other threads:[~2021-11-30 21:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-30 13:54 [Bug fortran/103496] New: " burnus at gcc dot gnu.org
2021-11-30 20:14 ` [Bug fortran/103496] " anlauf at gcc dot gnu.org
2021-11-30 21:02 ` burnus at gcc dot gnu.org [this message]
2024-04-10 17:19 ` anlauf at gcc dot gnu.org
2024-04-12  8:59 ` burnus at gcc dot gnu.org
2024-04-12 19:18 ` anlauf at gcc dot gnu.org
2024-04-23 18:25 ` cvs-commit at gcc dot gnu.org
2024-04-23 18:28 ` anlauf at gcc dot gnu.org

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=bug-103496-4-v3U1mTtBFH@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@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).