[Bug fortran/107266] New: Reject kind=4 characters for BIND(C) – it invalid and generates wrong code

[Bug fortran/107266] New: Reject kind=4 characters for BIND(C) – it invalid and generates wrong code

[burnus at gcc dot gnu.org]

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

            Bug ID: 107266
           Summary: Reject kind=4 characters for BIND(C) – it invalid and
                    generates wrong code
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Keywords: accepts-invalid, wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

There is code which expects that CHARACTER arguments inside BIND(C) procedures
is kind=1 (alias C_CHAR):

  if (sym->ts.type == BT_CHARACTER
      && ((sym->attr.function && sym->attr.is_bind_c)
          || ((sym->attr.result || sym->attr.value)
              && sym->ns->proc_name
              && sym->ns->proc_name->attr.is_bind_c)
          || (sym->ts.deferred && (!sym->ts.u.cl
                                   || !sym->ts.u.cl->backend_decl))))
    type = gfc_character1_type_node;
  else
    type = gfc_typenode_for_spec (&sym->ts, sym->attr.codimension);

If one now tries to use:

call foo(4_'abcd')
contains
subroutine foo(x)
  character(kind=4,len=4) :: x
  ...
end
end

this creates inconsistent interfaces!

Alternatively, if we want to support it, we need to change how this is handled
to yield proper code!

[Bug fortran/107266] Reject kind=4 characters for BIND(C) – it invalid and generates wrong code

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Better example:

character(kind=4) function f(x) bind(C)
  character(kind=4), value :: x
end


Has the dump:

__attribute__((fn spec (". w ")))
character(kind=1) f (character(kind=1) x)
{
  (void) 0;
}


Note the change to kind=1

[Bug fortran/107266] Reject kind=4 characters for BIND(C) – it invalid and generates wrong code

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #1)
> Better example:
> 
> character(kind=4) function f(x) bind(C)
>   character(kind=4), value :: x
> end
> 
> 
> Has the dump:
> 
> __attribute__((fn spec (". w ")))
> character(kind=1) f (character(kind=1) x)
> {
>   (void) 0;
> }
> 
> 
> Note the change to kind=1

So, you want gfortran to reject the function.

It gets real ugly with

function f(x) bind(C) result(a)
   character(kind=4) a
   character(kind=4), value :: x
   a = x
end

leading to

__attribute__((fn spec (". w ")))
character(kind=1) f (character(kind=1) x)
{
  character(kind=1) a;

  *(character(kind=4) *) &a = *(character(kind=4) *) &x;
  return a;
}

[Bug fortran/107266] Reject kind=4 characters for BIND(C) – it invalid and generates wrong code

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #2)
> (In reply to Tobias Burnus from comment #1)
> > Better example:
> > 
> > character(kind=4) function f(x) bind(C)
> >   character(kind=4), value :: x
> > end
> > 
> > 
> > Has the dump:
> > 
> > __attribute__((fn spec (". w ")))
> > character(kind=1) f (character(kind=1) x)
> > {
> >   (void) 0;
> > }
> > 
> > 
> > Note the change to kind=1
> 
> So, you want gfortran to reject the function.
> 
> It gets real ugly with
> 
> function f(x) bind(C) result(a)
>    character(kind=4) a
>    character(kind=4), value :: x
>    a = x
> end
> 
> leading to
> 
> __attribute__((fn spec (". w ")))
> character(kind=1) f (character(kind=1) x)
> {
>   character(kind=1) a;
> 
>   *(character(kind=4) *) &a = *(character(kind=4) *) &x;
>   return a;
> }

Looks like resolve.cc:resolve_symbol() might be able to dela with this.
For my function with the result variable one has

(gdb) p *sym
$4 = {name = 0x2041ec100 "f", module = 0x0, declared_at = {
    nextc = 0x203a38160, lb = 0x203a38140}, ts = {type = BT_UNKNOWN, kind = 0, 
...
    in_equivalence = 0, function = 1, subroutine = 0, procedure = 0, 
    generic = 0, generic_copy = 0, implicit_type = 0, untyped = 0, 
    is_bind_c = 1, extension = 0, is_class = 0, class_ok = 0, vtab = 0, 
...
   value = 0x0, as = 0x0, result = 0x203a57600, components = 0x0, 

(gdb) p *sym->result
$5 = {name = 0x2041ec110 "a", module = 0x0, declared_at = {
    nextc = 0x203a381dc, lb = 0x203a38140}, ts = {type = BT_CHARACTER, 
    kind = 4, u = {derived = 0x203a245a0, cl = 0x203a245a0, pad = 60966304}, 
...
    dummy = 0, result = 1, assign = 0, threadprivate = 0, 

so gfortran can check for kind=4 versus kind=1 (aka C_CHAR).

[Bug fortran/107266] Reject kind=4 characters for BIND(C) – it invalid and generates wrong code

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4

[Bug fortran/107266] Reject kind=4 characters for BIND(C) – it invalid and generates wrong code

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-10-14
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #4 from kargl at gcc dot gnu.org ---
This un-regression-tested patch

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index d133bc2d034..dfd59febf70 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -15509,6 +15509,33 @@ resolve_symbol (gfc_symbol *sym)
       return;
     }

+  /* A Function result with character(kind=4) cannot have the bind(c)
+     attribute, because c_char is assumed to match default character kind.  */
+  if (sym->attr.function && sym->attr.is_bind_c)
+    {
+      if (sym->ts.type == BT_CHARACTER
+         && sym->result->ts.kind != gfc_default_character_kind)
+       {
+         gfc_error ("Symbol %qs at %L with type CHARACTER(KIND=4) "
+                    "cannot have the BIND(C) attribute", sym->name,
+                    &sym->declared_at);
+         return;
+       }
+
+      if (sym->ts.type == BT_UNKNOWN
+         && sym->result
+         && sym->result->ts.type == BT_CHARACTER
+         && sym->result->ts.kind != gfc_default_character_kind)
+       {
+         gfc_error ("Function result variable %qs at %L with type "
+                    "CHARACTER(KIND=4) at %L cannot have the BIND(C) "
+                    "attribute",
+                    sym->result->name, &sym->result->declared_at,
+                    &sym->result->ts.u.cl->length->where);
+         return;
+       }
+    }
+
   if (sym->attr.artificial)
     return;

with this code

function f(x) bind(C) result(a)
   character(kind=4) a
   character(kind=4), value :: x
   a = x
end

character(kind=4) function g(x) bind(C)
   character(kind=4), value :: x
   g = x
end

yields
% gfcx -c  a.f90
a.f90:1:31:

    1 | function f(x) bind(C) result(a)
      |                               1
    2 |    character(kind=4) a
      |                    2           
Error: Function result variable 'a' at (1) with type CHARACTER(KIND=4) at (2)
cannot have the BIND(C) attribute
a.f90:7:28:

    7 | character(kind=4) function g(x) bind(C)
      |                            1
Error: Symbol 'g' at (1) with type CHARACTER(KIND=4) cannot have the BIND(C)
attribute


Tobias, once you regression test the patch, feel free to commit it.

[Bug fortran/107266] Reject kind=4 characters for BIND(C) – it invalid and generates wrong code

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> ---
I do note that we already have bind(C) + kind=4 examples:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/testsuite/gfortran.dg/PR100906.f90
  integer, parameter :: c_ucs4_char = 4
and more.

=> Keep permitting it but fix it

=> Patch: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603639.html

[Bug fortran/107266] Reject kind=4 characters for BIND(C) – it invalid and generates wrong code

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Fri, Oct 14, 2022 at 09:36:59PM +0000, burnus at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107266
> 
> --- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> ---
> I do note that we already have bind(C) + kind=4 examples:
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/testsuite/gfortran.dg/PR100906.f90
>   integer, parameter :: c_ucs4_char = 4
> and more.

F2023 does not have an interoperable type of c_ucs4_char.
F2023 has SELECTED_CHAR_KIND("ISO_10646"), which can be
used as in the example code (see 22-007r1.pdf, 16.9.180):

14 SUBROUTINE create_date_string(string)
15    INTRINSIC date_and_time,selected_char_kind
16    INTEGER,PARAMETER :: ucs4 = selected_char_kind("ISO_10646")
17    CHARACTER(1,UCS4),PARAMETER :: nen=CHAR(INT(Z'5e74'),UCS4), & !year
18      gatsu=CHAR(INT(Z'6708'),UCS4), & !month
19      nichi=CHAR(INT(Z'65e5'),UCS4) !day
20    CHARACTER(len= *, kind= ucs4) string
21    INTEGER values(8)
22    CALL date_and_time(values=values)
23    WRITE(string,1) values(1),nen,values(2),gatsu,values(3),nichi
24    1 FORMAT(I0,A,I0,A,I0,A)
25 END SUBROUTINE


Neither UCS4, ISO_10646, ISO 10646, nor 10646 appear in 
F2023 Section 18.

On J3 Fortran github, there are no proposals/requests for
interoperability with ISO 10646.

> => Keep permitting it but fix it

I'll update my patch to use "gfc_notify_std (GFC_STD_GNU, ...)"
as this is clearly an extension to the Fortran standard.

[Bug fortran/107266] Reject kind=4 characters for BIND(C) – it invalid and generates wrong code

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Here's the updated patch.  It will accept the code as before if -std= is absent
or -std=GNU.  For other -std= flags such as -std=f2018, one will get

%  gfcx -c -std=f2018 a.f90
a.f90:1:31:

    1 | function f(x) bind(C) result(a)
      |                               1
    2 |    character(kind=4) a
      |                    2           
Error: GNU Extension: Function result variable 'a' at (1) with type
CHARACTER(KIND=4) at (2) cannot have the BIND(C) attribute
a.f90:7:28:

    7 | character(kind=4) function g(x) bind(C)
      |                            1
Error: GNU Extension: Symbol 'g' at (1) with type CHARACTER(KIND=4) cannot have
the BIND(C) attribute


diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index d133bc2d034..db28cd05365 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -15509,6 +15509,29 @@ resolve_symbol (gfc_symbol *sym)
       return;
     }

+  /* A Function result with character(kind=4) cannot have the bind(c)
+     attribute, because c_char is assumed to match default character kind.  */
+  if (sym->attr.function && sym->attr.is_bind_c)
+    {
+      if (sym->ts.type == BT_CHARACTER
+         && sym->result->ts.kind != gfc_default_character_kind
+         && !gfc_notify_std (GFC_STD_GNU, "Symbol %qs at %L with type "
+                             "CHARACTER(KIND=4) cannot have the BIND(C) "
+                             "attribute", sym->name, &sym->declared_at))
+       return;
+
+      if (sym->ts.type == BT_UNKNOWN
+         && sym->result
+         && sym->result->ts.type == BT_CHARACTER
+         && sym->result->ts.kind != gfc_default_character_kind
+         && !gfc_notify_std (GFC_STD_GNU, "Function result variable %qs at "
+                             "%L with type CHARACTER(KIND=4) at %L cannot "
+                             "have the BIND(C) attribute", sym->result->name,
+                             &sym->result->declared_at,
+                             &sym->result->ts.u.cl->length->where))
+       return;
+    }
+
   if (sym->attr.artificial)
     return;

[Bug fortran/107266] Reject kind=4 characters for BIND(C) – it invalid and generates wrong code

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tobias Burnus <burnus@gcc.gnu.org>:

https://gcc.gnu.org/g:8950288333162caa68b85c71ed2d02f40976ddb9

commit r13-3338-g8950288333162caa68b85c71ed2d02f40976ddb9
Author: Tobias Burnus <tobias@codesourcery.com>
Date:   Mon Oct 17 18:15:16 2022 +0200

    Fortran: Fixes for kind=4 characters strings [PR107266]

            PR fortran/107266

    gcc/fortran/
            * trans-expr.cc (gfc_conv_string_parameter): Use passed
            type to honor character kind.
            * trans-types.cc (gfc_sym_type): Honor character kind.
            * trans-decl.cc (gfc_conv_cfi_to_gfc): Fix handling kind=4
            character strings.

    gcc/testsuite/
            * gfortran.dg/char4_decl.f90: New test.
            * gfortran.dg/char4_decl-2.f90: New test.

[Bug fortran/107266] Reject kind=4 characters for BIND(C) – it invalid and generates wrong code

[kargl at gcc dot gnu.org]

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

--- Comment #9 from kargl at gcc dot gnu.org ---
(In reply to CVS Commits from comment #8)
> The master branch has been updated by Tobias Burnus <burnus@gcc.gnu.org>:
> 
> https://gcc.gnu.org/g:8950288333162caa68b85c71ed2d02f40976ddb9
> 
> commit r13-3338-g8950288333162caa68b85c71ed2d02f40976ddb9
> Author: Tobias Burnus <tobias@codesourcery.com>
> Date:   Mon Oct 17 18:15:16 2022 +0200
> 
>     Fortran: Fixes for kind=4 characters strings [PR107266]
>     
>             PR fortran/107266
>     
>     gcc/fortran/
>             * trans-expr.cc (gfc_conv_string_parameter): Use passed
>             type to honor character kind.
>             * trans-types.cc (gfc_sym_type): Honor character kind.
>             * trans-decl.cc (gfc_conv_cfi_to_gfc): Fix handling kind=4
>             character strings.
>     
>     gcc/testsuite/
>             * gfortran.dg/char4_decl.f90: New test.
>             * gfortran.dg/char4_decl-2.f90: New test.

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.

[Bug fortran/107266] Reject kind=4 characters for BIND(C) – it invalid and generates wrong code

[burnus at gcc dot gnu.org]

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

--- Comment #10 from Tobias Burnus <burnus at gcc dot gnu.org> ---
First, the committed patch handles something which was wrong with *and* without
BIND(C) and fixed a genuine bug.

 * * *

(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.


(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:

"A Fortran procedure interface is interoperable with a C function prototype if
...
(5) any dummy argument without the VALUE attribute corresponds to a formal
parameter of the prototype that is of a pointer type, and either
...
• the dummy argument is a nonallocatable nonpointer variable of type CHARACTER
with assumed character length and the formal parameter is a pointer to
CFI_cdesc_t,
• the dummy argument is allocatable, assumed-shape, assumed-rank, or a pointer
without the
CONTIGUOUS attribute, and the formal parameter is a pointer to CFI_cdesc_t, or
..."

[Bug fortran/107266] Reject kind=4 characters for BIND(C) – it invalid and generates wrong code

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #11 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:
> 
> (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:

I'm going to assume that you did not compile the above, or
read the patch.

% gfcx -c a.f90
a.f90:1:22:

    1 | subroutine bar(x, y, z) bind(C)
      |                      1
Error: Allocatable character dummy argument 'z' at (1) must have deferred
length as procedure 'bar' is BIND(C)

% cat a.f90
subroutine bar(x, y, z) bind(C)
    character(kind=4,len=*) :: x
    character(kind=4) :: y(:)
    character(kind=4,len=:), allocatable :: z
end subroutine bar

% gfcx -c a.f90 && nm a.o | grep bar
0000000000000000 T bar
% gfcx -c -std=f2018 a.f90 && nm a.o | grep bar
0000000000000000 T bar

% cat a.f90 
character(kind=4) function bar(x, y, z) bind(C)
    character(kind=4,len=*) :: x
    character(kind=4) :: y(:)
    character(kind=4,len=:), allocatable :: z
end function bar

% gfcx -c a.f90 && nm a.o | grep bar
0000000000000000 T bar

% gfcx -c -std=f2018 a.f90
a.f90:1:30:

    1 | character(kind=4) function bar(x, y, z) bind(C)
      |                              1
Error: GNU Extension: Symbol 'bar' at (1) with type CHARACTER(KIND=4) cannot
have the BIND(C) attribute

The patch checks a *function* result variable for an interoperable
CHARACTER kind.

[Bug fortran/107266] Reject kind=4 characters for BIND(C) – it invalid and generates wrong code

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #12 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Tue, Oct 18, 2022 at 05:29:58PM +0000, sgk at troutmask dot
apl.washington.edu wrote:
> 
> % gfcx -c -std=f2018 a.f90
> a.f90:1:30:
> 
>     1 | character(kind=4) function bar(x, y, z) bind(C)
>       |                              1
> Error: GNU Extension: Symbol 'bar' at (1) with type CHARACTER(KIND=4) cannot
> have the BIND(C) attribute
> 
> The patch checks a *function* result variable for an interoperable
> CHARACTER kind.
> 

BTW, Fortran standard contains

C1553 If proc-language-binding-spec is specified for a function,
the function result shall be an interoperable scalar variable.

So, accepting "character(kind=4) foo() bind(c)" is questionable 
(unless kind=4 is C_CHAR, which it isn't).

[Bug fortran/107266] Reject kind=4 characters for BIND(C) – it invalid and generates wrong code

[sgk at troutmask dot apl.washington.edu]

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.