https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92284
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
Status|RESOLVED |NEW
Last reconfirmed| |2019-10-30
Resolution|INVALID |---
Ever confirmed|0 |1
--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to José Rui Faustino de Sousa from comment #4)
> The new code should ICE 10.0.0, but not 9.1.0, using either the C procedure
> or the Fortran bind(c) one.
I have now tried (using current GCC trunk + submitted but not committed patch
for PR92277):
Fortran + C program unmodified: works.
BUT:
* Leaks memory via _gfortran_gfc_desc_to_cfi_desc (ISO_Fortran_binding.c:100)
* valgrind reports "Conditional jump or move depends on uninitialised value(s)"
in _gfortran_gfc_desc_to_cfi_desc (ISO_Fortran_binding.c:132)"
for the call on the Fortran side (line 50).
Hence re-opened.
I think one of the recent patches has probably fixed the ICE, it might even the
PR92277 patch (which is not yet approved/committed) – See
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg02148.html
> Using just the "arr_set" procedure with bind(c) set is very likely a
> duplicate of PR 92189 like you mention.
Presumably – this should be re-checked, once one has a patch for PR 92189.
Looking at the memory leakage/mem-access issues:
* Memory leak: gfc_desc_to_cfi_desc actually allocates the array descriptor if
one has passed a pointer to NULL. That presumably means that one has to undo
the the free removal of r277502 for PR91863 – or at least something like that.
* The for-loops regarding the bounds should be guarded by "if
(GFC_DESCRIPTOR_DATA (s))" – as unallocated/unassociated arrays do not really
have array bounds
