https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110076
anlauf at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2023-06-01
Ever confirmed|0 |1
--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed. I believe I've seen another duplicate where running under gdb
shows that we enter an infinite loop in gfc_get_derived_type:
(gdb) l 2731,2753
2731 /* Go through the derived type components, building them as
2732 necessary. The reason for doing this now is that it is
2733 possible to recurse back to this derived type through a
2734 pointer component (PR24092). If this happens, the fields
2735 will be built and so we can return the type. */
2736 for (c = derived->components; c; c = c->next)
2737 {
2738 bool same_alloc_type = c->attr.allocatable
2739 && derived == c->ts.u.derived;
2740
2741 if (c->ts.type == BT_UNION && c->ts.u.derived->backend_decl ==
NULL)
2742 c->ts.u.derived->backend_decl = gfc_get_union_type
(c->ts.u.derived);
2743
2744 if (c->ts.type != BT_DERIVED && c->ts.type != BT_CLASS)
2745 continue;
2746
2747 if ((!c->attr.pointer && !c->attr.proc_pointer
2748 && !same_alloc_type)
2749 || c->ts.u.derived->backend_decl == NULL)
2750 {
2751 int local_codim = c->attr.codimension ? c->as->corank:
codimen;
2752 c->ts.u.derived->backend_decl = gfc_get_derived_type
(c->ts.u.derived,
2753
local_codim);
