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.
