public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "sgk at troutmask dot apl.washington.edu" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/107266] Reject kind=4 characters for BIND(C) – it invalid and generates wrong code Date: Tue, 18 Oct 2022 23:18:33 +0000 [thread overview] Message-ID: <bug-107266-4-QmfVb6eHTZ@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-107266-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107266 --- Comment #13 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- On Tue, Oct 18, 2022 at 10:40:59AM +0000, burnus at gcc dot gnu.org wrote: > > (In reply to kargl from comment #9) > > Please commit the patch in comment #7. character(kind=4) is not interoperable > > (unless C_CHAR is CHARACTER(KIND=4) which it isn't). This is an extension and > > gfortran should flag. > > While I concur that the example in comment 1 is not interoperable according to > the Fortran 2018 standard, I think the patch of comment 7 rejects too much (cf. > '(b)' below.) > > Still, I think something should/could be done – hence, I did not close this PR. > Namely: > > * * * > > For C interoperability, I think there are two parts to this: > > (a.1) module m; character(kind=4) :: c; end module m > (a.2) subroutine foo(x) bind(C) > character(kind=4) :: x > > To both the following applies (F2018, 18.3.1 Interoperability of intrinsic > types): > > "A Fortran intrinsic type with particular type parameter values is > interoperable with a C type if the type and kind type parameter value are > listed in the table on the same row as that C type. If the type is character, > the length type parameter is interoperable > if and only if its value is one." > > Hence, neither 'foo' nor 'c' are interoperable. I'm confused by what you are trying to show with (a.1). The standard has "If the length is not specified in a char-selector or a * char-length, the length is 1.", so that last sentence is no relevant. Moreover, there is no C binding issue as you did not write module m character(kind=4), bind(c) :: c end module m gfortran accepts the above when it should be rejected because of C820 A variable with the BIND attribute shall be interoperable (18.3). For (a.2), this should also be rejected per C1556 A variable that is a dummy argument of a procedure that has ar proc-language-binding-spec shall be assumed-type or of interoperable type and kind type parameters. > (b) subroutine bar(x, y, z) bind(C) > character(kind=4,len=*) :: x > character(kind=4) :: y(:) > character(kind=4), allocatable :: z > > This one is valid as F2018's "18.3.6 Interoperability of procedures and > procedure interfaces" states: > It's not valid per C1556 above and C1555 If proc-language-binding-spec is specified for a procedure, each dummy argument of type CHARACTER with the ALLOCATABLE or POINTER attribute shall have deferred character length.
prev parent reply other threads:[~2022-10-18 23:18 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-10-14 16:04 [Bug fortran/107266] New: " burnus at gcc dot gnu.org 2022-10-14 16:09 ` [Bug fortran/107266] " burnus at gcc dot gnu.org 2022-10-14 18:31 ` kargl at gcc dot gnu.org 2022-10-14 18:51 ` kargl at gcc dot gnu.org 2022-10-14 18:51 ` kargl at gcc dot gnu.org 2022-10-14 20:08 ` kargl at gcc dot gnu.org 2022-10-14 21:36 ` burnus at gcc dot gnu.org 2022-10-14 22:21 ` sgk at troutmask dot apl.washington.edu 2022-10-14 22:45 ` kargl at gcc dot gnu.org 2022-10-17 16:15 ` cvs-commit at gcc dot gnu.org 2022-10-17 16:56 ` kargl at gcc dot gnu.org 2022-10-18 10:40 ` burnus at gcc dot gnu.org 2022-10-18 17:29 ` sgk at troutmask dot apl.washington.edu 2022-10-18 22:43 ` sgk at troutmask dot apl.washington.edu 2022-10-18 23:18 ` sgk at troutmask dot apl.washington.edu [this message]
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-107266-4-QmfVb6eHTZ@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: linkBe 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).