https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125650
--- Comment #6 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
This is interesting, this passes on my worktree. It is probably a duplicate of
something I have fixed already.
The fix for PR125528 appears to have broken this. Draft patch testing.
diff --git a/gcc/fortran/match.cc b/gcc/fortran/match.cc
index e8f2cd8580c..86985e03892 100644
--- a/gcc/fortran/match.cc
+++ b/gcc/fortran/match.cc
@@ -2304,8 +2304,9 @@ match_association_list (bool for_change_team = false)
(.div. vector_t(init_fn, n=8))
additionally resolve the direct operands as constructor calls
(resolve_assoc_operand). Then call gfc_extend_expr on the
- outermost operator. Only handle INTRINSIC_USER here; arithmetic
- operators are left to the normal resolution pass. */
+ outermost operator. Overloaded intrinsic operators (+, -, //,
+ ==, etc.) keep their intrinsic INTRINSIC_* code rather than
+ INTRINSIC_USER and are handled by the simpler fallback below. */
gfc_expr *tmp = gfc_copy_expr (newAssoc->target);
extend_assoc_op (tmp->value.op.op1);
extend_assoc_op (tmp->value.op.op2);
@@ -2326,6 +2327,24 @@ match_association_list (bool for_change_team = false)
else
gfc_free_expr (tmp);
}
+ else if (newAssoc->target->ts.type == BT_UNKNOWN
+ && newAssoc->target->expr_type == EXPR_OP)
+ {
+ /* The selector is an unresolved expression involving an overloaded
+ intrinsic operator (e.g. a `+` bound via an explicit interface
+ to a function returning CHARACTER). Try to extend it now, the
+ same way the type-bound user-defined operator case above does
+ for INTRINSIC_USER, so the associate name gets a usable type
+ before the body of the ASSOCIATE construct is parsed. Without
+ this, references such as cc(3:5) to an associate name of
+ CHARACTER type are matched before the type is known and end up
+ malformed, leading to an ICE in trans-expr.cc. PR fortran/125650.
*/
+ gfc_expr *tmp = gfc_copy_expr (newAssoc->target);
+ if (gfc_extend_expr (tmp) == MATCH_YES)
+ gfc_replace_expr (newAssoc->target, tmp);
+ else
+ gfc_free_expr (tmp);
+ }
/* The `variable' field is left blank for now; because the target is not
yet resolved, we can't use gfc_has_vector_subscript to determine it
