From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17491 invoked by alias); 13 Oct 2010 09:23:56 -0000 Received: (qmail 17483 invoked by uid 22791); 13 Oct 2010 09:23:55 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate3.de.ibm.com (HELO mtagate3.de.ibm.com) (195.212.17.163) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 13 Oct 2010 09:23:49 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.1/8.13.1) with ESMTP id o9D9Nkqa012510 for ; Wed, 13 Oct 2010 09:23:46 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o9D9NkCS3838010 for ; Wed, 13 Oct 2010 11:23:46 +0200 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id o9D9NjHW012509 for ; Wed, 13 Oct 2010 11:23:45 +0200 Received: from leonard.localnet (dyn-9-152-224-33.boeblingen.de.ibm.com [9.152.224.33]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id o9D9NeoL012478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Oct 2010 11:23:45 +0200 From: Ken Werner To: Tom Tromey Subject: Re: [patch] fix pre-/post- in-/decrement Date: Wed, 13 Oct 2010 09:23:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-22-generic-pae; KDE/4.5.1; i686; ; ) Cc: Joel Brobecker , Daniel Jacobowitz , Ulrich Weigand , gdb-patches@sourceware.org References: <201010041301.o94D1QHV032611@d12av02.megacenter.de.ibm.com> <201010071438.00571.ken@linux.vnet.ibm.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010131123.40225.ken@linux.vnet.ibm.com> X-IsSubscribed: yes 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: 2010-10/txt/msg00213.txt.bz2 On Wednesday, October 13, 2010 1:00:04 am Tom Tromey wrote: > >>>>> "Ken" == Ken Werner writes: > Ken> I overlooked that in case of C++ the various assignment, > Ken> pre-increment and pre-decrement operators return lvalues while they > Ken> return non-lvalues for C. > > I still had this patch in my queue, but I wasn't sure if it was > obsoleted by something else... First, thank you for looking at this. In my opinion the patch is still relevant. The goal is to add unop support for vector types. The initial patch contained (beside its main purpose) code to prevent post in-/decrement operators from returning lvalues. Joel suggested this should be treated as a separate patch. This is how this patch was born. It helps GDB to be more accurate when it comes to the result types of unary operations. > While I don't really mind having language checks in the expression > evaluator, it seems like this particular error condition is something > that could be detected in the C parser. Hmm interesting. I guess you are referring to c-exp.y as this generates the expression parser for both languages C and C++. I don't see how to control the type of the result of an operator there. I'm still quite new to the GDB parsing internals and would appreciate any insights. > Also, I think the C++ rule is more complicated. I did not look through > the standard to find it, but g++ at least gives an error for a simple > scalar "x++ = 5". Yes, this behaviour seems correct to me and the patch ensures that a non- lvalue is returned in case of UNOP_POSTINCREMENT and UNOP_POSTDECREMENT as C and C++ do not differ here. For BINOP_ASSIGN, BINOP_ASSIGN_MODIFY, UNOP_PREINCREMENT and UNOP_PREDECREMENT C returns non-lvalues while C++ returns lvalues. This is why the patch checks the language and calls value_non_lval for languages other than C++. I think the relevant sections of the C++ standard are these: 5.3.2 Increment and decrement [expr.pre.incr]: "The result is the updated operand; it is an lvalue, [..]" 5.2.6 Increment and decrement [expr.post.incr] "The result is an rvalue." 5.17 Assignment and compound assignment operators [expr.ass] "[...] return an lvalue with the type and value of the left operand after the assignment has taken place." So, this patch doesn't conflict with the g++ behaviour you are seeing. Regards Ken Werner