Re: [PATCH] PR125528 ICE or wrong-code for ASSOCIATE selector that is a, type-bound user-defined operator

polite PING, I prefer to get this pushed before I push 125529 so I can keep my 
worktree sane

On 6/1/26 4:50 PM, Jerry D wrote:
> This one was what we call a 3-fer. Next in line on the PR125515 list.
> 
> See attached patch.
> 
> Regression tested on x86-64.
> 
> OK for mainline and then backport to 16?
> 
> Regards,
> 
> Jerry
> 
> ---
> 
> fortran: ICE or wrong-code for ASSOCIATE selector that is a
>   type-bound user-defined operator
> 
> Three related bugs prevented ASSOCIATE selectors that are type-bound
> user-defined operator expressions from compiling correctly.
> 
> Bug 1 (class.cc): find_typebound_proc_uop returned NULL immediately when
> the derived type has no f2k_derived namespace, bypassing the parent-type
> inheritance walk.  This caused inherited UDOs to be silently not found.
> Fix: set root = NULL and let the loop reach the parent type instead.
> 
> Bug 2 (resolve.cc): resolve_typebound_procedures called resolve_symbol on
> the parent type only after an early return that fires when the derived type
> has no direct type-bound bindings.  This left parent-type bindings
> unresolved when searched via gfc_find_typebound_user_op.
> Fix: move resolve_symbol(super_type) before the early return.
> 
> Bug 3 (match.cc): match_association_list did not handle ASSOCIATE selectors
> of the form .uop. expr or the nested case .uop2. (.uop1. expr).  When the
> selector's type was BT_UNKNOWN at parse time the name of the associate
> variable was left untyped, producing a "Syntax error in expression" ICE in
> the body of the ASSOCIATE construct.
> Fix: add three helpers before match_association_list:
>    - resolve_assoc_operand: attempts gfc_resolve_expr on EXPR_FUNCTION
>      operands and falls back to gfc_find_dt_in_generic for constructor calls
>      whose argument types are not yet known.
>    - infer_typebound_uop_type: reads the return type of a type-bound UDO
>      directly from specific_st->n.tb->u.specific->n.sym without calling
>      gfc_resolve_symbol, avoiding a resolve_symbol_called race condition.
>    - extend_assoc_op: walks the expression tree bottom-up, propagating
>      types through INTRINSIC_PARENTHESES wrappers before calling the two
>      helpers above on each INTRINSIC_USER node.
> When the selector is an INTRINSIC_USER EXPR_OP with BT_UNKNOWN type,
> call extend_assoc_op on the operands, then gfc_extend_expr (errors
> suppressed).  Accept the result when gfc_extend_expr returns MATCH_YES or
> when it returns MATCH_ERROR but has already converted the node to
> EXPR_COMPCALL with a known type (the full resolution pass finishes it).
> 
> PR fortran/125528
> 
> Assisted by: Claude Sonnet 4.6
> 
> gcc/fortran/ChangeLog:
> 
>      PR fortran/125528
>      * class.cc (find_typebound_proc_uop): Set root = NULL instead of
>      returning NULL when derived type lacks f2k_derived, so parent-type
>      type-bound procedures and operators are still found via inheritance.
>      * match.cc (resolve_assoc_operand): New helper.
>      (infer_typebound_uop_type): New helper.
>      (extend_assoc_op): New helper.
>      (match_association_list): Handle ASSOCIATE selectors that are
>      type-bound user-defined operator expressions, including nested cases.
>      * resolve.cc (resolve_typebound_procedures): Move resolve_symbol
>      call for the parent type before the early return so inherited
>      type-bound bindings are resolved even when the child type has none
>      of its own.
> 
> gcc/testsuite/ChangeLog:
> 
>      PR fortran/125528
>      * gfortran.dg/associate_80.f90: New test.
> ---