From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22434 invoked by alias); 20 Mar 2003 00:16:01 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 22356 invoked by uid 71); 20 Mar 2003 00:16:00 -0000 Date: Thu, 20 Mar 2003 00:16:00 -0000 Message-ID: <20030320001600.22348.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Neil Booth Subject: Re: c/10143: Post increment doesn work more than once per statement Reply-To: Neil Booth X-SW-Source: 2003-03/txt/msg01304.txt.bz2 List-Id: The following reply was made to PR c/10143; it has been noted by GNATS. From: Neil Booth To: Nick Macdonald Cc: "Joseph S. Myers" , Falk Hueffner , gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org Subject: Re: c/10143: Post increment doesn work more than once per statement Date: Thu, 20 Mar 2003 00:08:04 +0000 Nick Macdonald wrote:- > I was just trying to make the product better... I feel the answer of > "not a bug" to be a bit pedantic... sure, technically it may not be a > bug... however, logically, the current behaviour is less than stellar > and it should be addressed to make post and pre increment behave more or > less similarly... I have learned a valuable lesson from all this, and I Things aren't that clearcut - effectively, the compiler passes the code to the optimizer with a set of restrictions indicating what the optimizer can and cannot assume. Because of guarantees afforded by the standard, the optimizer is given pretty free reign, and munges your code. But that's only because it's wrong. It's not a matter of treating a or b consistently; just consider it a fluke that you observed the result you did. If you move a line of code you might see a different result, or GCC in 2 months time might, for any of a million reasons, decide to optimize it differently. Now, -Wsequence-point should have warned, but its algorithm is based on GCC trees, so consider me unsurprised at its fragility. None of this existed in 2.95, but it does in 3.2. Neil.