From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id CDF733858CDB; Thu, 30 Mar 2023 19:02:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CDF733858CDB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1680202952; bh=hEfr/CxydihOtSR/4X+2sLYPiWFV2dMvDNzqo6QrARw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=BWIgEiRNL+Dchoe9xJAD2LvRSe+h8gwhuhJcgq35aHkUwBRmHtWDfnI9tJD4sH2uv QMaG/SoE736rXtoINT4CfaupJtSV72X6Svj9gPSq2GiA3Og6ElvqdUnN2MBkbDPift R6LpghpyBbBl5RgI6dKpdk4TjQS4P6mFfWguQAYA= From: "sgk at troutmask dot apl.washington.edu" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes Date: Thu, 30 Mar 2023 19:02:32 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 12.2.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: sgk at troutmask dot apl.washington.edu X-Bugzilla-Status: WAITING X-Bugzilla-Resolution: X-Bugzilla-Priority: P5 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109322 --- Comment #9 from Steve Kargl -= -- 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=3D109322 >=20 > --- Comment #3 from Steve Kargl = --- > On Wed, Mar 29, 2023 at 05:50:05PM +0000, emr-gnu at hev dot psu.edu wrot= e: > >=20 > >=20 > > Extending my original demonstrator, if you add a "INTEGER(KIND=3DC_INT6= 4_T) :: > > E", you get the following output: > >=20 > > > gfortran -m32 -fc-prototypes -fsyntax-only foo.f90 > >=20 > > long a; > > {...} > > long_long e; > > } bar; >=20 > 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=20 > with gcc. Does 'gcc -m32' support "long_long"? If it > doesn't, then you'll need to hack on=20 >=20 > 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=3D8 IN" 2 value=3D8 INTEGER c_long 3 value=3D8 INTEGER c_long_long 4 value=3D8 INTEGER c_intmax_t 5 value=3D8 INTEGER c_intptr_t 6 value=3D8 INTEGER c_ptrdiff_t 7 value=3D8 INTEGER c_size_t 12 value=3D8 INTEGER c_int64_t 17 value=3D8 INTEGER c_int_least64_t 22 value=3D8 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=3D8 and INTEGER. It never reaches the 12th table entry for c_int64_t.=