Query regarding expression evaluation.

Query regarding expression evaluation.

[Ramana Radhakrishnan]

Hi , 

Look at PR1978 . The discrepancy is because in valarith.c , GDB takes
the operation to be unsigned depending only on the operand types. In the
case described in the PR this seems alright with respect to the C
standard since the result is implementation dependent. 

Is it GDB policy to make sure that all expression evaluation is similar
to expression eval done by GCC for cases regarding implementation
dependent semantics ?  

cheers
Ramana


-- 
Ramana Radhakrishnan
GNU Tools
codito ergo sum (www.codito.com)

Re: Query regarding expression evaluation.

[Andreas Schwab]

Ramana Radhakrishnan <ramana.radhakrishnan@codito.com> writes:

> Look at PR1978 . The discrepancy is because in valarith.c , GDB takes
> the operation to be unsigned depending only on the operand types. In the
> case described in the PR this seems alright with respect to the C
> standard since the result is implementation dependent. 

For the shift operator the result is completely independent of the type of
the right operand.  So the way gdb evaluates the expression is clearly
wrong.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Query regarding expression evaluation.

[Andreas Schwab]

Ramana Radhakrishnan <ramana.radhakrishnan@codito.com> writes:

> Look at PR1978 . The discrepancy is because in valarith.c , GDB takes
> the operation to be unsigned depending only on the operand types. In the
> case described in the PR this seems alright with respect to the C
> standard since the result is implementation dependent. 

Here is a fix:

2005-08-11  Andreas Schwab  <schwab@suse.de>

	PR exp/1978
	* valarith.c (value_binop): Fix result type for the shift
	operators.

--- gdb/valarith.c.~1.41.~	2005-07-07 11:12:12.000000000 +0200
+++ gdb/valarith.c	2005-08-10 18:22:48.000000000 +0200
@@ -883,7 +883,14 @@ value_binop (struct value *arg1, struct 
          Use the signedness of the operand with the greater length.
          If both operands are of equal length, use unsigned operation
          if one of the operands is unsigned.  */
-      if (promoted_len1 > promoted_len2)
+      if (op == BINOP_RSH || op == BINOP_LSH)
+	{
+	  /* In case of the shift operators the type of the result only
+	     depends on the type of the left operand.  */
+	  unsigned_operation = is_unsigned1;
+	  result_len = promoted_len1;
+	}
+      else if (promoted_len1 > promoted_len2)
 	{
 	  unsigned_operation = is_unsigned1;
 	  result_len = promoted_len1;

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Query regarding expression evaluation.

[Daniel Jacobowitz]

On Thu, Aug 11, 2005 at 12:10:51PM +0200, Andreas Schwab wrote:
> Ramana Radhakrishnan <ramana.radhakrishnan@codito.com> writes:
> 
> > Look at PR1978 . The discrepancy is because in valarith.c , GDB takes
> > the operation to be unsigned depending only on the operand types. In the
> > case described in the PR this seems alright with respect to the C
> > standard since the result is implementation dependent. 
> 
> Here is a fix:
> 
> 2005-08-11  Andreas Schwab  <schwab@suse.de>
> 
> 	PR exp/1978
> 	* valarith.c (value_binop): Fix result type for the shift
> 	operators.

This is OK - thanks!

-- 
Daniel Jacobowitz
CodeSourcery, LLC