RFA: Don't try to take address of SIMD vectors

RFA: Don't try to take address of SIMD vectors

[Jim Blandy]

This is, in some sense, a followup to:

    http://sources.redhat.com/ml/gdb-patches/2002-05/msg00027.html

No regressions on i686-pc-linux-gnu or powerpc-unknown-linux-gnu;
fixes vector subscripting on PowerPC E500 SIMD vectors.

2004-08-09  Jim Blandy  <jimb@redhat.com>

	* eval.c (evaluate_subexp_with_coercion): Don't try to produce a
	pointer to the value's first element if it's a SIMD vector value,
	not an ordinary array.

Index: gdb/eval.c
===================================================================
RCS file: /cvs/src/src/gdb/eval.c,v
retrieving revision 1.41
diff -c -p -r1.41 eval.c
*** gdb/eval.c	8 Apr 2004 21:18:12 -0000	1.41
--- gdb/eval.c	9 Aug 2004 23:01:19 -0000
*************** evaluate_subexp_with_coercion (struct ex
*** 2157,2162 ****
--- 2157,2163 ----
    int pc;
    struct value *val;
    struct symbol *var;
+   struct type *type;
  
    pc = (*pos);
    op = exp->elts[pc].opcode;
*************** evaluate_subexp_with_coercion (struct ex
*** 2165,2171 ****
      {
      case OP_VAR_VALUE:
        var = exp->elts[pc + 2].symbol;
!       if (TYPE_CODE (check_typedef (SYMBOL_TYPE (var))) == TYPE_CODE_ARRAY
  	  && CAST_IS_CONVERSION)
  	{
  	  (*pos) += 4;
--- 2166,2179 ----
      {
      case OP_VAR_VALUE:
        var = exp->elts[pc + 2].symbol;
!       type = check_typedef (SYMBOL_TYPE (var));
! 
!       /* If the variable's value is an array, produce a pointer to its
!          first element.  But if it's a SIMD vector, leave it alone ---
!          we can't do address arithmetic to find their elements, and
!          value_subscript handles them specially.  */
!       if (TYPE_CODE (type) == TYPE_CODE_ARRAY
!           && ! TYPE_VECTOR (type)
  	  && CAST_IS_CONVERSION)
  	{
  	  (*pos) += 4;

Re: RFA: Don't try to take address of SIMD vectors

[Daniel Jacobowitz]

On Tue, Aug 10, 2004 at 02:26:17AM -0500, Jim Blandy wrote:
> 
> This is, in some sense, a followup to:
> 
>     http://sources.redhat.com/ml/gdb-patches/2002-05/msg00027.html
> 
> No regressions on i686-pc-linux-gnu or powerpc-unknown-linux-gnu;
> fixes vector subscripting on PowerPC E500 SIMD vectors.
> 
> 2004-08-09  Jim Blandy  <jimb@redhat.com>
> 
> 	* eval.c (evaluate_subexp_with_coercion): Don't try to produce a
> 	pointer to the value's first element if it's a SIMD vector value,
> 	not an ordinary array.

Hi Jim,

I see that this patch was never checked in.  I can't convince myself
from the above that it's necessary; if you still want it, could you
show some examples?  Bonus points if they fit in the testsuite.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFA: Don't try to take address of SIMD vectors

[Jim Blandy]

Daniel Jacobowitz <drow@false.org> writes:
> On Tue, Aug 10, 2004 at 02:26:17AM -0500, Jim Blandy wrote:
> > 
> > This is, in some sense, a followup to:
> > 
> >     http://sources.redhat.com/ml/gdb-patches/2002-05/msg00027.html
> > 
> > No regressions on i686-pc-linux-gnu or powerpc-unknown-linux-gnu;
> > fixes vector subscripting on PowerPC E500 SIMD vectors.
> > 
> > 2004-08-09  Jim Blandy  <jimb@redhat.com>
> > 
> > 	* eval.c (evaluate_subexp_with_coercion): Don't try to produce a
> > 	pointer to the value's first element if it's a SIMD vector value,
> > 	not an ordinary array.
> 
> Hi Jim,
> 
> I see that this patch was never checked in.  I can't convince myself
> >From the above that it's necessary; if you still want it, could you
> show some examples?  Bonus points if they fit in the testsuite.

If I have a variable v which is a SIMD vector type, and I write

        f (v)

does the compiler treat v like an array, and pass its address to f, or
does it treat it like a struct, and pass it by value?  I don't have my
E500 tools all set up at the moment, but I believe it passes it by
value.

The other thing, I believe, is that subscripting vectors located in
registers relies on using value_subscripted_rvalue.  If you try to
coerce a value living in a register to a pointer, you get an error
before you get there.