public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "sandra at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libfortran/101305] New: Bind(C): Problems with incorrect kinds/sizes in ISO_Fortran_binding.h and CFI_establish Date: Sat, 03 Jul 2021 05:48:47 +0000 [thread overview] Message-ID: <bug-101305-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101305 Bug ID: 101305 Summary: Bind(C): Problems with incorrect kinds/sizes in ISO_Fortran_binding.h and CFI_establish Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: sandra at gcc dot gnu.org CC: burnus at gcc dot gnu.org, jrfsousa at gcc dot gnu.org Target Milestone: --- ISO_Fortran_binding.h incorrectly hard-codes literal data sizes into the CFI_type_* macros that are only appropriate on a 64-bit target, such as CFI_type_ptrdiff_t having the same kind (8) as CFI_type_int64_t. Even on x86_64-linux-gnu, CFI_type_int_fast16_t and CFI_type_int_fast32_t have kinds that are inconsistent with the sizes of the corresponding types as defined in the system headers. In addition, the standard says: "If a C type is not interoperable with a Fortran type and kind supported by the Fortran processor, its macro shall evaluate to a negative value." ISO_Fortran_binding.h doesn't handle that (I think this mainly affects the 128-bit types GCC supports as an extension on some targets). There are related problems in CFI_establish in filling in the elem_len in the descriptor from the kind. It incorrectly ends up giving zero elem_len to CFI_type_cptr and CFI_type_cfunptr, and explicitly gives size 64(!) to long double kind 10. It should probably reject unsupported types with CFI_INVALID_TYPE. There are test cases in the WIP TS 29113 testsuite: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574115.html interoperability/typecodes-array.f90 interoperability/typecodes-array-ext.f90 interoperability/typecodes-scalar.f90 interoperability/typecodes-scalar-ext.f90 library/establish.f90 This issue has some overlap with the set of bugs addressed by this patch from José (PR fortran/100906/100907/100911/100914/100915/100916): https://gcc.gnu.org/pipermail/fortran/2021-June/056154.html but that patch is focused on the Fortran side of things rather than the C side. Tobias and I both have WIP patches for this issue that need to be merged (his is for handling detection of Fortran processor support, mine is to use sizeof instead of hard-coding sizes). Probably all 3 pieces need to be in place for this to work correctly.
next reply other threads:[~2021-07-03 5:48 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-03 5:48 sandra at gcc dot gnu.org [this message] 2021-07-06 20:11 ` [Bug libfortran/101305] " sandra at gcc dot gnu.org 2021-07-08 19:03 ` sandra at gcc dot gnu.org 2021-07-14 0:08 ` sandra at gcc dot gnu.org 2021-07-28 4:24 ` cvs-commit at gcc dot gnu.org 2021-07-28 4:24 ` cvs-commit at gcc dot gnu.org 2021-07-28 4:24 ` cvs-commit at gcc dot gnu.org 2021-07-28 20:21 ` sandra at gcc dot gnu.org 2021-08-09 10:36 ` cvs-commit at gcc dot gnu.org 2021-08-10 15:27 ` cvs-commit at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-101305-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).