Dear all,
happy New Year!
The testcase committed with the fix for PR93337 uncovered a latent issue
with an invalid read that was discovered with an ASAN instrumented compiler
but which could also be verified by running f951 under valgrind.
According to my gdb sessions the invalid read happens when processing a
statement that refers to a rejected declaration of a CLASS instance.
We simply should not try to look up the vtab entry in such cases.
All variations of the testcase gfortran.dg/pr93337.f90 that I tried on
x86_64-pc-linux-gnu with the patch below appeared to behave clean running
f951 under valgrind.
Regtested on x86_64-pc-linux-gnu.
OK for master? Since the fix for PR93337 was applied to 9/10/11, I intend
to backport after suitable waiting time.
Thanks,
Harald
PR fortran/96381 - invalid read in gfc_find_derived_vtab
An invalid declaration of a CLASS instance can lead to an internal state
with inconsistent attributes during parsing that needs to be handled with
sufficient care when processing subsequent statements. Avoid a lookup of
the vtab entry for such cases.
gcc/fortran/ChangeLog:
* class.c (gfc_find_vtab): Add check on attribute is_class.
diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 5677d920239..783e4c7354b 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -2906,7 +2906,9 @@ gfc_find_vtab (gfc_typespec *ts)
case BT_DERIVED:
return gfc_find_derived_vtab (ts->u.derived);
case BT_CLASS:
- if (ts->u.derived->components && ts->u.derived->components->ts.u.derived)
+ if (ts->u.derived->attr.is_class
+ && ts->u.derived->components
+ && ts->u.derived->components->ts.u.derived)
return gfc_find_derived_vtab (ts->u.derived->components->ts.u.derived);
else
return NULL;
