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.

      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: 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).