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