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