From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3F3BC385C409; Tue, 30 Nov 2021 21:02:57 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3F3BC385C409 From: "burnus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: =?UTF-8?B?W0J1ZyBmb3J0cmFuLzEwMzQ5Nl0gW0YyMDE4XVtUUzI5MTEzXSBD?= =?UTF-8?B?X1NJWkVPRiDigJMgcmVqZWN0cyBub3cgdmFsaWQgYXJncyB3aXRoICdtdXN0?= =?UTF-8?B?IGJlIGFuIGludGVyb3BlcmFibGUgZGF0YSBlbnRpdHkn?= Date: Tue, 30 Nov 2021 21:02:57 +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.0 X-Bugzilla-Keywords: rejects-valid X-Bugzilla-Severity: normal X-Bugzilla-Who: burnus at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2021 21:02:57 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103496 --- Comment #2 from Tobias Burnus --- (In reply to anlauf from comment #1) > https://j3-fortran.org/doc/year/21/21-134r2.txt > but it still requires using interoperable types etc. > Just asking: did you simply forget to "decorate" your declarations? If you talk about something like 'kind=3Dc_int': On most systems, c_int =3D= =3D c_int32_t =3D=3D 4 - and gfortran has (by default) a default integer =3D=3D= 4. But also 'kind=3D8' is very likely to be interoperable; whether it is with c_long or= only c_int64_t or ... does not really matter in case of c_sizeof =E2=80=93 we ju= st need to know that some C type exists, which is interoperable. [Likewise, integer(kind=3Dc_int128_t) may or may not be interoperable, depending whether that kind is available - and if not, c_int128_t should be= a negative number. (Ignoring for now that c_int128_t is a vendor extension.)] But granted, usually you want to be sure that kind matches a specific C int= eger type and then c_... becomes useful and more portable. * * * 'interoperable type': I have to admit that I tend to get confused whether * "18.3.5 Interoperability of array variables" applies or whether also * "18.3.6 Interoperability of procedures and procedure interfaces" applies. In the latter case, array descriptors are permitted - and that per= mits allocatables, pointer, sub-sections etc. The former is more restrictive by = only permitting explicit shape or assumed size =E2=80=93 while the latter permit= s more. Given that the current wording for c_sizeof is about "that is not an assumed-size array or an assumed-rank array that is associated with an assumed-size array." I think one reasonable reading is that 18.3.6 applies as 18.3.5 does not pe= rmit assumed rank. As 21-134r2 shows, the current wording is not ideal =E2=80=93 but at the en= d, the modification just implies that 18.3.5 applies (IMHO).=