[Bug libfortran/92027] [10 regression] gfortran.dg/ISO_Fortran_binding_10.f90 FAILs – conditional jump based on uninitialized memory in runtime/ISO_Fortran_binding.c

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92027

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2019-10-17
                 CC|                            |burnus at gcc dot gnu.org,
                   |                            |pault at gcc dot gnu.org
            Summary|[10 regression]             |[10 regression]
                   |gfortran.dg/ISO_Fortran_bin |gfortran.dg/ISO_Fortran_bin
                   |ding_10.f90 FAILs           |ding_10.f90 FAILs –
                   |                            |conditional jump based on
                   |                            |uninitialized memory in
                   |                            |runtime/ISO_Fortran_binding
                   |                            |.c
     Ever confirmed|0                           |1

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> ---
The only libgfortran change in this range is r276624.

Namely:
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00422.html

    2019-10-05  Paul Thomas  <pault@gcc.gnu.org>

            PR fortran/91926
            * runtime/ISO_Fortran_binding.c (cfi_desc_to_gfc_desc): Do not
            modify the bounds and offset for CFI_other.

The code changed:
-  d->dtype.attribute = (signed short)s->attribute;
+  if (d->dtype.attribute == CFI_attribute_other)
+    return;


If I run it with valgrind, it shows:

==24369== Conditional jump or move depends on uninitialised value(s)
==24369==    at 0x4A7D63C: _gfortran_cfi_desc_to_gfc_desc
(ISO_Fortran_binding.c:66)

That's the "d->dtype.attribute". Seemingly, it is not guaranteed that "d" is
initialized.


At a glance, I do not see the reason for this change. It looks clearly
unrelated to the test cases and the issue reported in PR fortran/91926.