public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/109322] New: -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes
@ 2023-03-28 21:20 emr-gnu at hev dot psu.edu
2023-03-29 17:13 ` [Bug fortran/109322] " kargl at gcc dot gnu.org
` (10 more replies)
0 siblings, 11 replies; 12+ messages in thread
From: emr-gnu at hev dot psu.edu @ 2023-03-28 21:20 UTC (permalink / raw)
To: gcc-bugs
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;
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes
2023-03-28 21:20 [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
@ 2023-03-29 17:13 ` kargl at gcc dot gnu.org
2023-03-29 17:50 ` emr-gnu at hev dot psu.edu
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: kargl at gcc dot gnu.org @ 2023-03-29 17:13 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes
2023-03-28 21:20 [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
2023-03-29 17:13 ` [Bug fortran/109322] " kargl at gcc dot gnu.org
@ 2023-03-29 17:50 ` emr-gnu at hev dot psu.edu
2023-03-29 19:42 ` sgk at troutmask dot apl.washington.edu
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: emr-gnu at hev dot psu.edu @ 2023-03-29 17:50 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes
2023-03-28 21:20 [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
2023-03-29 17:13 ` [Bug fortran/109322] " kargl at gcc dot gnu.org
2023-03-29 17:50 ` emr-gnu at hev dot psu.edu
@ 2023-03-29 19:42 ` sgk at troutmask dot apl.washington.edu
2023-03-29 21:24 ` pinskia at gcc dot gnu.org
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2023-03-29 19:42 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes
2023-03-28 21:20 [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
` (2 preceding siblings ...)
2023-03-29 19:42 ` sgk at troutmask dot apl.washington.edu
@ 2023-03-29 21:24 ` pinskia at gcc dot gnu.org
2023-03-29 21:28 ` pinskia at gcc dot gnu.org
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-03-29 21:24 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes
2023-03-28 21:20 [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
` (3 preceding siblings ...)
2023-03-29 21:24 ` pinskia at gcc dot gnu.org
@ 2023-03-29 21:28 ` pinskia at gcc dot gnu.org
2023-03-29 21:30 ` pinskia at gcc dot gnu.org
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-03-29 21:28 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes
2023-03-28 21:20 [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
` (4 preceding siblings ...)
2023-03-29 21:28 ` pinskia at gcc dot gnu.org
@ 2023-03-29 21:30 ` pinskia at gcc dot gnu.org
2023-03-29 21:45 ` sgk at troutmask dot apl.washington.edu
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-03-29 21:30 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes
2023-03-28 21:20 [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
` (5 preceding siblings ...)
2023-03-29 21:30 ` pinskia at gcc dot gnu.org
@ 2023-03-29 21:45 ` sgk at troutmask dot apl.washington.edu
2023-03-29 21:47 ` pinskia at gcc dot gnu.org
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2023-03-29 21:45 UTC (permalink / raw)
To: gcc-bugs
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);
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes
2023-03-28 21:20 [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
` (6 preceding siblings ...)
2023-03-29 21:45 ` sgk at troutmask dot apl.washington.edu
@ 2023-03-29 21:47 ` pinskia at gcc dot gnu.org
2023-03-30 19:02 ` sgk at troutmask dot apl.washington.edu
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-03-29 21:47 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes
2023-03-28 21:20 [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
` (7 preceding siblings ...)
2023-03-29 21:47 ` pinskia at gcc dot gnu.org
@ 2023-03-30 19:02 ` sgk at troutmask dot apl.washington.edu
2023-03-30 19:21 ` pinskia at gcc dot gnu.org
2023-03-30 20:10 ` sgk at troutmask dot apl.washington.edu
10 siblings, 0 replies; 12+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2023-03-30 19:02 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes
2023-03-28 21:20 [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
` (8 preceding siblings ...)
2023-03-30 19:02 ` sgk at troutmask dot apl.washington.edu
@ 2023-03-30 19:21 ` pinskia at gcc dot gnu.org
2023-03-30 20:10 ` sgk at troutmask dot apl.washington.edu
10 siblings, 0 replies; 12+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-03-30 19:21 UTC (permalink / raw)
To: gcc-bugs
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 ).
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes
2023-03-28 21:20 [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
` (9 preceding siblings ...)
2023-03-30 19:21 ` pinskia at gcc dot gnu.org
@ 2023-03-30 20:10 ` sgk at troutmask dot apl.washington.edu
10 siblings, 0 replies; 12+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2023-03-30 20:10 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2023-03-30 20:10 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-28 21:20 [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
2023-03-29 17:13 ` [Bug fortran/109322] " kargl at gcc dot gnu.org
2023-03-29 17:50 ` emr-gnu at hev dot psu.edu
2023-03-29 19:42 ` sgk at troutmask dot apl.washington.edu
2023-03-29 21:24 ` pinskia at gcc dot gnu.org
2023-03-29 21:28 ` pinskia at gcc dot gnu.org
2023-03-29 21:30 ` pinskia at gcc dot gnu.org
2023-03-29 21:45 ` sgk at troutmask dot apl.washington.edu
2023-03-29 21:47 ` pinskia at gcc dot gnu.org
2023-03-30 19:02 ` sgk at troutmask dot apl.washington.edu
2023-03-30 19:21 ` pinskia at gcc dot gnu.org
2023-03-30 20:10 ` sgk at troutmask dot apl.washington.edu
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).