[Bug fortran/109322] New: -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes

[Bug fortran/109322] New: -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes

[emr-gnu at hev dot psu.edu]

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

            Bug ID: 109322
           Summary: -fc-prototypes does not correctly translate
                    INTEGER(KIND=C_SIZE_T), and other sizes
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: emr-gnu at hev dot psu.edu
  Target Milestone: ---

When generating C-prototypes, the gfortran compiler translates stdint.h
typedefs to their destination types at invocation time, rather than leaving
that to the C/C++ compiler in the translated code.  Example: C_SIZE_T is
translated to "long" rather than "size_t" in the generated prototype
structures. This holds true for function parameters and return values as well.

foo.f90:

MODULE FOO
 USE, INTRINSIC :: ISO_C_BINDING
 IMPLICIT NONE
 PUBLIC :: BAR
 TYPE, BIND(C) :: BAR
  INTEGER(KIND=C_SIZE_T) :: A = -1
  INTEGER(KIND=C_INT32_T) :: B = -1
  INTEGER(KIND=C_INT16_T) :: C = -1
  INTEGER(KIND=C_INT8_T) :: D = -1
 END TYPE
END MODULE

The above produces the following output:

> gfortran -fc-prototypes -fsyntax-only foo.f90

 typedef struct bar {
  long a;
  int b;
  short c;
  signed char d;
 } bar;


--------------

Expected output:

 typedef struct bar {
  size_t a;
  int32_t b;
  int16_t c;
  int8_t d;
 } bar;

[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
           Priority|P3                          |P5
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
You stated what you think gfortran ought to produce, but you
did not articulate a "why?"  What problem are you trying to fix?
The prototype generated by -fc-prototypes correspond to the C
companion processor, and may not be portable to other C processors
such as tinyC or bcc.

Also note, C_SIZE_T etc are simply named constants for kind
type parameters.   All of INTEGER, INTEGER(4), INTEGER(C_INT),
and INTEGER(C_INT32_t) have the same value of 4 for the default
integer kind on 32-bit architectures in the absence of any
command line option (such as -finteger-4-integer-8).

[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes

[emr-gnu at hev dot psu.edu]

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

--- Comment #2 from Eric Reischer <emr-gnu at hev dot psu.edu> ---
I can't point to a specific standard that says, "thou shalt generate output
with these types..."; it's more of a "we probably should be doing this"-type
thing.  If you are compiling Fortran and C on the same system with the same
compiler suite, this is a non-issue.  However, if you are, say, creating an API
that has autogenerated files redistributed (e.g., a base Fortran package and
then autogenerated and distributed C/C++ header files), the types generated
using -fc-prototypes are not safely transportable to another compiler with the
requested variable sizes.

This is probably better demonstrated with another example:

Extending my original demonstrator, if you add a "INTEGER(KIND=C_INT64_T) ::
E", you get the following output:

> gfortran -m32 -fc-prototypes -fsyntax-only foo.f90

 long a;
 {...}
 long_long e;
} bar;

-------

In the above, "long_long" is nonstandard and not recognized by most compilers
(it was apparently implemented in some locations as a workaround to a problem
on Windows with gcc compatibility).

What's worse, is if you run the above in 64-bit mode on x86 Linux, you get:

> gfortran -m64 -fc-prototypes -fsyntax-only foo.f90
 long a;
 {...}
 long e;
} bar;

-------

This is most definitely wrong -- "long" will be 64 bits on Linux, but only 32
bits on Windows, so the size type emitted is ambiguous.  Additionally, the
structures will no longer be interoperable, because (again, on Windows) in
C/C++ you'll get a variable "E" that will only store 32 bits, whereas in
Fortran the corresponding variable will be 64 bits, thus offsetting every
variable that comes after it. Probably better to be safe (and definitely more
portable) to leave translation of the types to when the C/C++ files are
actually compiled (which may not be with gcc) by using the stdint.h types.

I will stipulate that, yes, int64_t is not *guaranteed* to be exactly 64 bits,
and size_t is not *guaranteed* to be 32 or 64 bits (based on what architecture
you're running).  But preserving the explicitly-specified data types across the
language translation is the point here.  An entirely separate argument could be
had for INTEGER*4, INTEGER*8, etc., but in this case, since you're explicitly
requesting C_INTxx_T, you're getting something else entirely out of the
prototype-generation subsystem.

[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Mar 29, 2023 at 05:50:05PM +0000, emr-gnu at hev dot psu.edu wrote:
> 
> 
> Extending my original demonstrator, if you add a "INTEGER(KIND=C_INT64_T) ::
> E", you get the following output:
> 
> > gfortran -m32 -fc-prototypes -fsyntax-only foo.f90
> 
>  long a;
>  {...}
>  long_long e;
> } bar;

The companion C processor is gcc.  It is generating
prototypes for that C processor.  If one is manipulating
the environment with a command line option such as -m32
or -m64, then one likely needs to use the same option 
with gcc.  Does 'gcc -m32' support "long_long"?  If it
doesn't, then you'll need to hack on 

gcc/fortran/dump-parse-tree.cc
gcc/fortran/iso-c-binding.def
gcc/fortran/trans-types.cc

[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2023-03-29
     Ever confirmed|0                           |1

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Eric Reischer from comment #2)
> However, if you are, say, creating an
> API that has autogenerated files redistributed (e.g., a base Fortran package
> and then autogenerated and distributed C/C++ header files), the types
> generated using -fc-prototypes are not safely transportable to another
> compiler with the requested variable sizes.

Yes you should use this option this wayt; you can always post process the
generated headers.
For -m32 vs -m64, you could generate two headers and have a master header that
includes one or another.
There is no way to store these headers in a repo unless you post process them.

[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
There is a bug with -m32 and fc-prototypes though, it should be long long
rather than long long. Let me provide a patch for that.

[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
diff --git a/gcc/fortran/dump-parse-tree.cc b/gcc/fortran/dump-parse-tree.cc
index 3b24bdc1a6c..7869130ac2b 100644
--- a/gcc/fortran/dump-parse-tree.cc
+++ b/gcc/fortran/dump-parse-tree.cc
@@ -3697,6 +3697,8 @@ get_c_type_name (gfc_typespec *ts, gfc_array_spec *as,
const char **pre,
              && c_interop_kinds_table[i].value == ts->kind)
            {
              *type_name = c_interop_kinds_table[i].name + 2;
+             if (strcmp (*type_name, "long_long") == 0)
+               *type_name = "long long";
              if (strcmp (*type_name, "signed_char") == 0)
                *type_name = "signed char";
              else if (strcmp (*type_name, "size_t") == 0)

[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Mar 29, 2023 at 09:28:38PM +0000, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322
> 
> --- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> There is a bug with -m32 and fc-prototypes though, it should be long long
> rather than long long. Let me provide a patch for that.
> 

This replaces '_' by ' ', but would certainly break if int_t
is in type_name.

diff --git a/gcc/fortran/dump-parse-tree.cc b/gcc/fortran/dump-parse-tree.cc
index 3b24bdc1a6c..3921adfbe01 100644
--- a/gcc/fortran/dump-parse-tree.cc
+++ b/gcc/fortran/dump-parse-tree.cc
@@ -3807,6 +3807,7 @@ write_decl (gfc_typespec *ts, gfc_array_spec *as, const
char *sym_name,
            bool func_ret, locus *where, bool bind_c)
 {
   const char *pre, *type_name, *post;
+  char *bp, buf[81];
   bool asterisk;
   enum type_return rok;

@@ -3819,7 +3820,15 @@ write_decl (gfc_typespec *ts, gfc_array_spec *as, const
char *sym_name,
               gfc_typename (ts));
       return;
     }
-  fputs (type_name, dumpfile);
+
+#if 1
+  bp = &buf[0];
+  strncpy(bp, type_name, 80);
+  for (; *bp != '\0'; bp++)
+    if (*bp == '_') *bp = ' ';
+#endif
+
+  fputs (buf, dumpfile);
   fputs (pre, dumpfile);
   if (asterisk)
     fputs ("*", dumpfile);

[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Steve Kargl from comment #7)
> On Wed, Mar 29, 2023 at 09:28:38PM +0000, pinskia at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322
> > 
> > --- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> > There is a bug with -m32 and fc-prototypes though, it should be long long
> > rather than long long. Let me provide a patch for that.
> > 
> 
> This replaces '_' by ' ', but would certainly break if int_t
> is in type_name.

Right which is why my patch in comment #6 is reasonable. I am going to commit
it as obvious after my bootstrap/test is finished.

[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #9 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Mar 29, 2023 at 07:42:08PM +0000, sgk at troutmask dot
apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322
> 
> --- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
> On Wed, Mar 29, 2023 at 05:50:05PM +0000, emr-gnu at hev dot psu.edu wrote:
> > 
> > 
> > Extending my original demonstrator, if you add a "INTEGER(KIND=C_INT64_T) ::
> > E", you get the following output:
> > 
> > > gfortran -m32 -fc-prototypes -fsyntax-only foo.f90
> > 
> >  long a;
> >  {...}
> >  long_long e;
> > } bar;
> 
> The companion C processor is gcc.  It is generating
> prototypes for that C processor.  If one is manipulating
> the environment with a command line option such as -m32
> or -m64, then one likely needs to use the same option 
> with gcc.  Does 'gcc -m32' support "long_long"?  If it
> doesn't, then you'll need to hack on 
> 
> gcc/fortran/dump-parse-tree.cc
> gcc/fortran/iso-c-binding.def
> gcc/fortran/trans-types.cc

If one instruments, write_decl() in dump-parse-tree.cc to
dump the table of bind(c) types, one can see why you get
what you get.

% cat a.f90
module foo
 use, intrinsic :: iso_c_binding
 implicit none
 public :: bar
 type, bind(c) :: bar
  integer(c_int64_t) a
 end type
end module

% gfcx -fc-prototypes -fsyntax-only a.f90 | grep "value=8 IN"
  2 value=8 INTEGER c_long
  3 value=8 INTEGER c_long_long
  4 value=8 INTEGER c_intmax_t
  5 value=8 INTEGER c_intptr_t
  6 value=8 INTEGER c_ptrdiff_t
  7 value=8 INTEGER c_size_t
 12 value=8 INTEGER c_int64_t
 17 value=8 INTEGER c_int_least64_t
 22 value=8 INTEGER c_int_fast64_t

typedef struct bar {
    long a;
} bar;

The for-loop in write_decl() breaks on the first match to
to both value=8 and INTEGER.  It never reaches the 12th
table entry for c_int64_t.

[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Steve Kargl from comment #9)
> 
> If one instruments, write_decl() in dump-parse-tree.cc to
> dump the table of bind(c) types, one can see why you get
> what you get.
> 
> % cat a.f90
> module foo
>  use, intrinsic :: iso_c_binding
>  implicit none
>  public :: bar
>  type, bind(c) :: bar
>   integer(c_int64_t) a
>  end type
> end module
> 
> % gfcx -fc-prototypes -fsyntax-only a.f90 | grep "value=8 IN"
>   2 value=8 INTEGER c_long
>   3 value=8 INTEGER c_long_long
>   4 value=8 INTEGER c_intmax_t
>   5 value=8 INTEGER c_intptr_t
>   6 value=8 INTEGER c_ptrdiff_t
>   7 value=8 INTEGER c_size_t
>  12 value=8 INTEGER c_int64_t
>  17 value=8 INTEGER c_int_least64_t
>  22 value=8 INTEGER c_int_fast64_t
> 
> typedef struct bar {
>     long a;
> } bar;
> 
> The for-loop in write_decl() breaks on the first match to
> to both value=8 and INTEGER.  It never reaches the 12th
> table entry for c_int64_t.

For ILP32 (32bit x86) and LLP64IL32 (64bit Windows/mingw) targets, it will use
c_long_long which is outputted wrong. Anyways I fixed the bug with respect of
c_long_long being outputted incorrectly as long_long rather than "long long"
too. (r13-6940-ga7df3bea9cf1e4 and backported to GCC 12:
r12-9370-g429b75db39aa89 ).

[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #11 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, Mar 30, 2023 at 07:21:21PM +0000, pinskia at gcc dot gnu.org wrote:
> 
> For ILP32 (32bit x86) and LLP64IL32 (64bit Windows/mingw) targets, it will use
> c_long_long which is outputted wrong. Anyways I fixed the bug with respect of
> c_long_long being outputted incorrectly as long_long rather than "long long"
> too. (r13-6940-ga7df3bea9cf1e4 and backported to GCC 12:
> r12-9370-g429b75db39aa89 ).
> 

I quite agree that your patch fixed a problem.  My
comment was meant for the OP, who would like to
"integer(c_int64_t) a" translated to "int64_t a;"
That's isn't going to happen anytime soon.  I left
the PR open as an enhancement request.  In 10 years,
if I'm still around I close it.