From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8747 invoked by alias); 5 Oct 2010 13:42:11 -0000 Received: (qmail 8731 invoked by uid 22791); 5 Oct 2010 13:42:10 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 05 Oct 2010 13:42:05 +0000 Received: (qmail 31324 invoked from network); 5 Oct 2010 13:42:04 -0000 Received: from unknown (HELO caradoc.them.org) (dan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Oct 2010 13:42:04 -0000 Date: Tue, 05 Oct 2010 13:42:00 -0000 From: Daniel Jacobowitz To: Ulrich Weigand Cc: Ken Werner , gdb-patches@sourceware.org, Joel Brobecker , Vladimir Prus Subject: Re: [patch] fix pre-/post- in-/decrement Message-ID: <20101005134200.GJ6985@caradoc.them.org> References: <20101005011650.GF6985@caradoc.them.org> <201010051328.o95DSJ8L027985@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201010051328.o95DSJ8L027985@d12av02.megacenter.de.ibm.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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/msg00047.txt.bz2 On Tue, Oct 05, 2010 at 03:28:19PM +0200, Ulrich Weigand wrote: > Daniel Jacobowitz wrote: > > On Tue, Oct 05, 2010 at 01:24:51AM +0200, Ulrich Weigand wrote: > > > - If you execute "set *$p = *$q = 0" and the write to *$q fails, > > > do you really expect *$p to be set to the old value of *$q > > > instead of to 0? > > > > Yes, I would expect that. To me, this is roughly "the debugger treats > > all pointers as volatile". > > The thing is, I had interpreted the C standard to read that even if > pointers p and q *are* volatile, a statement like "*p = *q = 0" would > still just trigger two writes, and no reads. You're right, I remember Nathan's recent arguments about this on gcc-patches. > "Assignments are also expressions and have an rvalue. However when assigning > to a scalar volatile, the volatile object is not reread, regardless of whether > the assignment expression's rvalue is used or not. If the assignment's rvalue > is used, the value is that assigned to the volatile object. [...] If you need > to read the volatile object after an assignment has occurred, you must use a > separate expression with an intervening sequence point." > To reduce the potential for confusion, it seems to me GDB ought to mirror > that behavior as well ... Hmm. It seems to me that this is a disruptive change for us, because the "a = b" case is more likely to be used than anything fancy (a += b, a = b = c). If we change it, we should document the change. Vladimir, would this interact with your recent varobj changes? We worked out exactly which reads we wanted, but I don't remember if value_assign is involved. -- Daniel Jacobowitz CodeSourcery