Hi,

I noticed that with the current GDB it is possible to assign values to 
not_lval-vector-values. Consider the following sample code:
  /* gcc -g -maltivec -mabi=altivec altivec.c -o altivec */
  #include <altivec.h>
  int test () {
    return 1;
  }
  vector int vtest () {
    return (vector int) {0, 1, 2, 3};
  }
  int main () {
    return 0;
  }

Here is the corresponding gdb session:
  gdb ./altivec
  start
  [...]
  (gdb) p test()
  $1 = 1
  (gdb) p &test()
  Attempt to take address of value not located in memory.
  (gdb) set variable test() = 2
  Left operand of assignment is not an lvalue.
  (gdb)  
  (gdb) 
  (gdb) p vtest()
  $2 = {0, 1, 2, 3}
  (gdb) p &vtest()
  $3 = (__vector signed int *) 0x10020008
  (gdb) set variable vtest() = {3, 2, 1, 0}
  (gdb) p vtest()
  $4 = {0, 1, 2, 3}

As can be seen the GDB behaves incorrect for vector types. A quick look to the 
valops.c:value_assign function shows that value_coerce_to_target creates a 
value with lval set to lval_memory for array types (including vectors). The 
code was introduced with the following patch: http://sourceware.org/ml/gdb-
patches/2008-03/msg00079.html. I have to admit that I do not entirely 
understand why value_coerce_to_target is called here. The attached patch adds 
a check for vector types within value_coerce_to_target and extends the 
altivec-abi testcase. Tested on powerpc64-*-linux-gnu, no regressions. Any 
suggestions are welcome.

Regards
-ken