From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18661 invoked by alias); 5 Oct 2010 13:28:36 -0000 Received: (qmail 18648 invoked by uid 22791); 5 Oct 2010 13:28:34 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,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; Tue, 05 Oct 2010 13:28:26 +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 o95DSMZv020017 for ; Tue, 5 Oct 2010 13:28:22 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o95DSKja3981490 for ; Tue, 5 Oct 2010 15:28:22 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id o95DSKNS028040 for ; Tue, 5 Oct 2010 15:28:20 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id o95DSJ8L027985; Tue, 5 Oct 2010 15:28:19 +0200 Message-Id: <201010051328.o95DSJ8L027985@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 05 Oct 2010 15:28:19 +0200 Subject: Re: [patch] fix pre-/post- in-/decrement To: dan@codesourcery.com (Daniel Jacobowitz) Date: Tue, 05 Oct 2010 13:28:00 -0000 From: "Ulrich Weigand" Cc: ken@linux.vnet.ibm.com (Ken Werner), gdb-patches@sourceware.org, brobecker@adacore.com (Joel Brobecker) In-Reply-To: <20101005011650.GF6985@caradoc.them.org> from "Daniel Jacobowitz" at Oct 04, 2010 09:16:59 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/msg00046.txt.bz2 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. Current GCC implementation agrees with this reading: This code: int f (volatile int *p) { return *p = 0; } void g (volatile int *p, int *result) { *result = *p = 0; } compiles to (using gcc-head -O2 on i386): f: movl 4(%esp), %eax movl $0, (%eax) xorl %eax, %eax ret g: movl 4(%esp), %eax movl $0, (%eax) movl 8(%esp), %eax movl $0, (%eax) ret However, it seems this was not always completely clear, and until very recently, the implementation in GCC was not quite consistent either: E.g. using Ubuntu 4.4.3 we get: f: movl 4(%esp), %eax movl $0, (%eax) xorl %eax, %eax <<= retval is hard-coded to 0 ret g: movl 4(%esp), %eax movl $0, (%eax) movl (%eax), %edx <<= extra read from *p movl 8(%esp), %eax movl %edx, (%eax) ret This behavior was discussed at length on the GCC mailing list starting at: http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02001.html resulting in the behavior as now described at: http://gcc.gnu.org/onlinedocs/gcc/Volatiles.html#Volatiles "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." The current behavior is consistent with what C++ requires, and what most other C compilers implement as well. To reduce the potential for confusion, it seems to me GDB ought to mirror that behavior as well ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com