Re: [PATCH] Vector to scalar casting and widening

["Ulrich Weigand" <uweigand@de.ibm.com>]

Andrew Burgess wrote:
> On 19/11/2012 9:16 PM, Tom Tromey wrote:
> >>>>>> "Andrew" == Andrew Burgess <aburgess@broadcom.com> writes:
> > 
> > Andrew> I'd like to change the way gdb handles scalar to vector
> > Andrew> widening.  I believe that the changes I propose will bring gdb
> > Andrew> expression evaluation into line with how gcc handles these
> > Andrew> things; this seems a good thing to me, but I'd be interested to
> > Andrew> hear why anyone things we should stick with the current scheme.

This difference between OpenCL semantics and GCC is a bit annoying;
for the most part, GCC vector extensions were chosen to match (or
at least extend) OpenCL semantics.  But in the particular case of
explicit conversion between integer and vector types it seems
the behaviour of the GCC extension dates way back to 2000 or so,
long before we even had OpenCL ...

Given that, I agree that we ought to match GCC's behaviour when
targeting non-OpenCL languages.

> In order to maintain current opencl behaviour I've created a new patch,
> this one has a flag on the language_defn structure to control how vector
> casting functions.  I reuse the vector widening code where appropriate.
> The choices then are:
>  1. vector to vector cast
>     1.1 This is not allowed in OpenCL (see above pdf) so I throw an error.
>     1.2 This is only allowed for gcc/c vectors if they are the same size,
>         otherwise throw an error.
>  2. scalar to vector cast
>     2.1 For OpenCL, cast scalar to vector element type and replicate.
>     2.2 For gcc/c vectors, only allow if the scalar is the same size as
>         the vector.

However, I'm not sure I like the new language_defn flag.  Generally, the
OpenCL code has kept all expression evaluation that differs from the
default behaviour local in evaluate_subexp_opencl; see e.g. the treatment
of relational operations.

Thus, I'd prefer a patch that:
 - changes the default behaviour of value_cast etc. to the GCC behaviour, and
 - adds handling of UNOP_CAST etc. to evaluate_subexp_opencl to implement the
   OpenCL semantics.

> I've tested the standard non-opencl side of things, but haven't been able
> to figure out how to run the opencl tests (any pointers welcome), so I don't
> know if I've broken any of those tests.

Unfortunately the only environment I know of to test the GDB OpenCL support
is the IBM OpenCL SDK for PowerPC.  I'll be happy to run the test for you ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com