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

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> ---
That's a slightly bogus diagnostic. The code is called for reading from a
".mod" file and does:

                gfc_typespec ts;
                mio_typespec (&ts);

The called function does:

  ts->type = MIO_NAME (bt) (ts->type, bt_types);

which (with some detour) expands to:

mio_name (int t, const mstring *m)
{
  if (iomode == IO_OUTPUT)
    write_atom (ATOM_NAME, gfc_code2string (m, t));
  else
    {
      require_atom (ATOM_NAME);
      t = find_enum (m);
    }
}

Thus, for reading/input, the memory of 'ts' is never actually read from,
i.e. there is no real bug. - However, as 'ts' is referenced, the code is
still a bit questionable.

Solution: I think either calling 'gfc_clear_ts' which manually sets all
elements to 0/nullptr – or just doing the following should cure this:

--- a/gcc/fortran/module.cc
+++ b/gcc/fortran/module.cc
@@ -4488,3 +4488,3 @@ mio_omp_declare_simd_clauses (gfc_omp_clauses **clausesp)
              {
-               gfc_typespec ts;
+               gfc_typespec ts = {};
                mio_typespec (&ts);

Reply via email to