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);