From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12415 invoked by alias); 26 Nov 2012 14:18:22 -0000 Received: (qmail 12405 invoked by uid 22791); 26 Nov 2012 14:18:21 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,MSGID_FROM_MTA_HEADER,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from e06smtp13.uk.ibm.com (HELO e06smtp13.uk.ibm.com) (195.75.94.109) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 26 Nov 2012 14:18:17 +0000 Received: from /spool/local by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 26 Nov 2012 14:18:15 -0000 Received: from b06cxnps4074.portsmouth.uk.ibm.com (9.149.109.196) by e06smtp13.uk.ibm.com (192.168.101.143) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 26 Nov 2012 14:18:05 -0000 Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by b06cxnps4074.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qAQEHv1T000504 for ; Mon, 26 Nov 2012 14:17:57 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qAQEI4rZ008155 for ; Mon, 26 Nov 2012 07:18:04 -0700 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id qAQEI3Kv008073; Mon, 26 Nov 2012 07:18:03 -0700 Message-Id: <201211261418.qAQEI3Kv008073@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 26 Nov 2012 15:18:03 +0100 Subject: Re: [PATCH] Vector to scalar casting and widening To: aburgess@broadcom.com (Andrew Burgess) Date: Mon, 26 Nov 2012 14:18:00 -0000 From: "Ulrich Weigand" Cc: tromey@redhat.com (Tom Tromey), gdb-patches@sourceware.org (gdb-patches@sourceware.org), ken@linux.vnet.ibm.com (Ken Werner) In-Reply-To: <50AFA38D.3040602@broadcom.com> from "Andrew Burgess" at Nov 23, 2012 04:25:49 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit x-cbid: 12112614-2966-0000-0000-000005FCEB0A Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-11/txt/msg00650.txt.bz2 Andrew Burgess wrote: > On 19/11/2012 9:16 PM, Tom Tromey wrote: > >>>>>> "Andrew" == Andrew Burgess 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