Thanks Paul,
The master branch has been updated by Jerry DeLisle <[email protected]>:
https://gcc.gnu.org/g:8c57a6b7959dcf16ed5321cd5214f66e7e6ad4d7
commit r17-1357-g8c57a6b7959dcf16ed5321cd5214f66e7e6ad4d7
Will backport after a period of time.
Jerry
On 6/4/26 3:25 AM, Paul Richard Thomas wrote:
Hi Jerry,
I have refactored the patch somewhat in the attached to keep match.cc
clean and push all the operator expansion to intrinsic.cc.
Either version LGTM and both pass regression testing. OK for mainline
and eventual backporting.
Thanks!
Paul
On Wed, 3 Jun 2026 at 17:51, Jerry D <[email protected]> wrote:
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.
---
