On 15 October 2025 19:41:12 CEST, Bernhard Reutner-Fischer <[email protected]> wrote: >On 12 October 2025 21:03:51 CEST, Jerry D <[email protected]> wrote: >>On 10/12/25 6:28 AM, Paul Richard Thomas wrote: >>> The attached patch is straightforward and sufficiently explained in >>> the ChangeLog and the comment in the patch. Seemingly, the gimplifier >>> objects to an empty loop body emerging from structure_alloc_comps. The >>> ICE arose in the reporter's test case because of the deallocate >>> statement generated in the finalization wrapper. If a similar problem >>> arises elsewhere, the fix might well be refactored by adding another >>> PDT attribute and setting it in decl.cc (gfc_get_pdt_instance) but I >>> see no advantage in doing that now. >>> >>> Regtest with FC42/x86_64. OK for mainline. >>> >>> Paul >> >>Reviewed and tested here. >> >>OK for mainline. >> >>Thanks once again Paul! > >Yes, thanks. > >As a micro optimization, would it make sense to break early? > >+ bool parameterized_comps = false; >+ for (gfc_component *c = der_type->components; c; c = c->next) > > >s/; c;/; c || parameterized_comps;/
well in the right order or just return true. Or does some pass do this for us anyway already? If so, which one? thanks
