On Thu, Feb 12, 2026 at 01:53:45PM -0500, Patrick Palka wrote:
> On Thu, 12 Feb 2026, Patrick Palka wrote:
>
> > On Thu, 12 Feb 2026, Jason Merrill wrote:
> >
> > > On 2/12/26 5:43 AM, Patrick Palka wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > > OK for trunk/15?
> > > >
> > > > -- >8 --
> > > >
> > > > The object argument of an xobj memfn call needs to be evaluated before
> > > > its formal arguments, like with an iobj memfn call. This patch
> > > > generalizes the existing METHOD_TYPE callee evaluation order handling
> > > > in cp_gimplify_expr to also handle xobj memfn callees. (The handling
> > > > needs to look at both fntype and decl because the callee can be e.g. an
> > > > OBJ_TYPE_REF for which decl would be NULL.)
> > >
> > > It seems to me that this sequencing is a property of the syntax "a.f ("
> > > ([expr.call]/7) rather than of the function; it is not required for e.g.
> > > "(*&A::f) (a, ++a.m)". Though it is still allowed under "indeterminately
> > > sequenced", so this is OK with an added comment.
> >
> > AFAICT the METHOD_TYPE check is needed more for virtual function calls,
> > e.g. m_fallback->seek(newPos) in g++.dg/pr121757.C, where the callee is
> > expressed as OBJ_TYPE_REF:
> >
> > OBJ_TYPE_REF(*NON_LVALUE_EXPR <NON_LVALUE_EXPR <((struct
> > QQmlPreviewFileEngine *)
> > this)->m_fallback>->_vptr.QAbstractFileEngine>;(struct
> > QAbstractFileEngine)NON_LVALUE_EXPR <((struct QQmlPreviewFileEngine *)
> > this)->m_fallback>->0B)
> > (NON_LVALUE_EXPR <((struct QQmlPreviewFileEngine *) this)->m_fallback>,
> > newPos);
> >
> > So I suppose we want to continue evaluating the callee first there,
> > given the syntactic form.
> >
> > For (&A::f)(a, ++a.m) we express it the same as a.f(++a.m):
> >
> > A::f (TARGET_EXPR <D.3029, a>, ++a.m);
> >
> > and so checking 'decl' will cover both forms.
> >
> > We also express (a.*&A::g)(...) the same as a.g(...), so checking
> > 'decl' will also cover both forms (checking METHOD_TYPE will too).
>
> ... unless of course the pointer-to-member callee is unknown!
>
> I just noticed the cp_get_callee_fndecl_nofold (*expr_p) == NULL_TREE
> logic earlier in cp_gimplify_expr, which IIUC will cause us evaluate
> an unknown callee first and foremost. But that's a separate question.
>
> This is what I'm going to commit:
>
> -- >8 --
>
> Subject: [PATCH] c++: evaluation order of xobj memfn call [PR123989]
>
> The object argument of an xobj memfn call needs to be evaluated before
> its formal arguments, like with an iobj memfn call. This patch
> generalizes the existing METHOD_TYPE callee evaluation order handling
> in cp_gimplify_expr to also handle xobj memfn callees.
>
> PR c++/123989
>
> gcc/cp/ChangeLog:
>
> * cp-gimplify.cc (cp_gimplify_expr) <case CALL_EXPR>: Evaluate
> the object argument of an xobj memfn call first too.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/cpp23/explicit-obj-eval-order.C: New test.
>
> Reviewed-by: Jason Merrill <[email protected]>
> ---
> gcc/cp/cp-gimplify.cc | 9 ++++++++-
> .../g++.dg/cpp23/explicit-obj-eval-order.C | 16 ++++++++++++++++
> 2 files changed, 24 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/g++.dg/cpp23/explicit-obj-eval-order.C
>
> diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc
> index 5ccfeefa6982..17d7cb4d9233 100644
> --- a/gcc/cp/cp-gimplify.cc
> +++ b/gcc/cp/cp-gimplify.cc
> @@ -921,7 +921,14 @@ cp_gimplify_expr (tree *expr_p, gimple_seq *pre_p,
> gimple_seq *post_p)
> tree fntype = TREE_TYPE (CALL_EXPR_FN (*expr_p));
> if (INDIRECT_TYPE_P (fntype))
> fntype = TREE_TYPE (fntype);
> - if (TREE_CODE (fntype) == METHOD_TYPE)
> + tree decl = cp_get_callee_fndecl_nofold (*expr_p);
> + /* We can't just rely on 'decl' because virtual function callees
> + are expressed as OBJ_TYPE_REF. Though checking for METHOD_TYPE
> + means we'll also sequence PMF calls, which is allowed under
> + "indeterimnately sequenced". */
Typo: indeterminately
> + if (TREE_CODE (fntype) == METHOD_TYPE
> + || (decl && DECL_LANG_SPECIFIC (decl)
> + && DECL_XOBJ_MEMBER_FUNCTION_P (decl)))
> {
> int nargs = call_expr_nargs (*expr_p);
> bool side_effects = false;
> diff --git a/gcc/testsuite/g++.dg/cpp23/explicit-obj-eval-order.C
> b/gcc/testsuite/g++.dg/cpp23/explicit-obj-eval-order.C
> new file mode 100644
> index 000000000000..7ce81f32cc4b
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp23/explicit-obj-eval-order.C
> @@ -0,0 +1,16 @@
> +// PR c++/123989
> +// { dg-do run { target c++23 } }
> +
> +struct A {
> + int m = 42;
> +
> + void f(this A self, int n) {
> + if (self.m != 42 || n != 43)
> + __builtin_abort();
> + }
> +};
> +
> +int main() {
> + A a;
> + a.f(++a.m);
> +}
> --
> 2.53.0.80.g6fcee47852
>
Marek
