Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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