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