From: Chris Moller <cmoller@redhat.com>
To: tromey@redhat.com
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [patch] pr11594
Date: Tue, 22 Jun 2010 19:57:00 -0000 [thread overview]
Message-ID: <4C2115AE.408@redhat.com> (raw)
In-Reply-To: <m34oguewvg.fsf@fleche.redhat.com>
On 06/22/10 14:38, Tom Tromey wrote:
>
> Chris> case BINOP_COMMA:
> Chris> - evaluate_subexp (NULL_TYPE, exp, pos, noside);
> Chris> - return evaluate_subexp (NULL_TYPE, exp, pos, noside);
> Chris> + arg1 = evaluate_subexp (NULL_TYPE, exp, pos, noside);
> Chris> + arg2 = evaluate_subexp (value_type (arg1), exp, pos, noside);
> Chris> + if (noside == EVAL_SKIP)
> Chris> + goto nosideret;
> Chris> + if (current_language->la_language == language_cplus
> Chris> + && binop_user_defined_p (op, arg1, arg2))
> Chris> + {
> Chris> + struct value *rc;
> Chris> +
> Chris> + rc = value_x_binop (arg1, arg2, op, OP_NULL, noside);
> Chris> + if (rc != NULL)
> Chris> + return rc;
> Chris> + else
> Chris> + return arg2;
>
> I think I understand why the current_language check and the result check
> of value_x_binop are needed.
>
> However, I think it would be better to do all the work in value_x_binop
> and also remove the current_language check. This is more similar to
> what other code does and it consolidates the (broken) current_language
> checks in the value code.
>
> I'm guessing this means a change to value_user_defined_op.
>
I went down that route--that's what's taken so long about getting this
patch out. Under some circumstances, you wind up special-case checking
for BINOP_COMMA and strcmp("operator," ) all over the place and
eventually wind up in a place where there's not enough contextual
information left to determine if you're dealing with an overloaded comma
and call value_addr() that tries to take the target address of a
register value.
The value_x_binop() result is checked because binop_user_defined_p()
only asserts that it's possible for the operands to represent an
overload, not that there is in fact an overload in this instance.
That's apparently determined in value_x_binop() and if the operator
isn't overloaded, I'm defaulting back to non-overloaded behaviour. (It
seems to me that the language check ought to be in
binop_user_defined_p() or binop_types_user_defined_p()--is there ever a
circumstance other than language_cplus where you can have overloaded
operators?)
If the language check really is unacceptable, I'll revisit this, but the
patch gets significantly more complicated.
I'm going to back-burner this, though--I've gone back to the matrix
pretty-print stuff for a while.
-cm
next prev parent reply other threads:[~2010-06-22 19:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-22 12:11 Chris Moller
2010-06-22 18:38 ` Tom Tromey
2010-06-22 19:57 ` Chris Moller [this message]
2010-06-23 17:38 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C2115AE.408@redhat.com \
--to=cmoller@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox