https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108434
anlauf at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|anlauf at gcc dot gnu.org |unassigned at gcc dot
gnu.org
Status|ASSIGNED |NEW
--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #10)
> Created attachment 59454 [details]
> Potential fix for comment 1
Hi Paul,
this is an interesting attempt! It fixes the testcases here, but ICEs when
adding the following obvious declaration
> program p
> type c
> integer :: i
> end type
> type t
> class(c), allocatable :: a(2)
> end type
> type s
> class(d), allocatable :: a(2)
> end type
type u
type(e), allocatable :: b(2)
end type
> class(t), pointer :: y1
> class(t), allocatable :: x1
> class(s), pointer :: y2
> class(s), allocatable :: x2
> end
> I am not sure that the chunk in resolve.cc is needed any more but it doesn't
> do any harm!
I also do not see that it is needed nor doing any harm, but why don't you
protect the line before the for loop?
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 565d4aa5fe9..0db6f0b2f1e 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -14599,7 +14599,7 @@ gfc_resolve_finalizers (gfc_symbol* derived, bool
*finalizable)
/* Ensure that derived-type components have a their finalizers resolved. */
bool has_final = derived->f2k_derived && derived->f2k_derived->finalizers;
- for (c = derived->components; c; c = c->next)
+ for (c = derived ? derived->components : NULL; c; c = c->next)
if (c->ts.type == BT_DERIVED
&& !c->attr.pointer && !c->attr.proc_pointer && !c->attr.allocatable)
{
If we were to get here with derived == NULL, one could use:
bool has_final = (derived
&& derived->f2k_derived
&& derived->f2k_derived->finalizers);
just to be consistent.
I am unassigning for now to pass this PR to you! :-)
(BTW: running f951 under valgrind shows many invalid reads for my extension
of your testcase above.)
