[Bug fortran/101635] New: FAIL: gfortran.dg/PR93963.f90 – alias-handling issue with BIND(C)'s _gfortran_cfi_desc_to_gfc_desc
burnus at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Tue Jul 27 08:34:34 GMT 2021
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101635
Bug ID: 101635
Summary: FAIL: gfortran.dg/PR93963.f90 – alias-handling issue
with BIND(C)'s _gfortran_cfi_desc_to_gfc_desc
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jrfsousa at gcc dot gnu.org, sandra at gcc dot gnu.org
Target Milestone: ---
This is kind of a regression as the testcase is new with the
commit r12-2511-g0cbf03689e3e7d9d6002b8e5d159ef3716d0404c
for PR 93308, PR 93963, PR 94327, PR 94331, and PR 97046.
The testcase gfortran.dg/PR93963.f90 has the following;
the → lines are from the -fdump-tree-original:
integer(kind=c_int), pointer :: intp(:)
nullify(intp)
irnk = rank_p(intp) ! this is BIND(C) with an assumed-rank argument
and the dump
intp.dtype = {.elem_len=4, .rank=1, .type=1};
intp.data = 0B;
and for the rank_p call:
void * cfi.6;
if ((integer(kind=4)[0:] *) intp.data == 0B)
{
intp.dtype = {.elem_len=4, .rank=1, .type=1};
}
_gfortran_gfc_desc_to_cfi_desc (&cfi.6, &intp);
irnk = rank_p (cfi.6);
__builtin_free (cfi.6);
With -m32 + optimizations, there seems to be an alias analysis issue which
causes that in rank_p, the argument's rank is <0 or >15 – such that rank_p
returns -1000. Unsurprisingly,
-1000 != 1
and, hence, the program runs into:
if (irnk /= rnk) stop 1
* * *
Solution: I think the proper fix is to remove both
_gfortran_gfc_desc_to_cfi_desc and _gfortran_cfi_desc_to_gfc_desc from
libgfortran/runtime/ISO_Fortran_binding.c and create inline code in the
compiler itself, i.e. in gcc/fortran/trans-expr.c's
gfc_conv_gfc_desc_to_cfi_desc and in gcc/fortran/trans-decl.c's
convert_CFI_desc.
The code in libgfortran is rather simple - and in the compiler itself,
knowledge about the type can be used, avoiding both type alias issues and
generating proper code – it also improves the performance.
More information about the Gcc-bugs
mailing list