From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3163 invoked by alias); 18 Jun 2005 18:05:17 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 3149 invoked by uid 22791); 18 Jun 2005 18:05:11 -0000 Received: from rwcrmhc14.comcast.net (HELO rwcrmhc14.comcast.net) (216.148.227.89) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sat, 18 Jun 2005 18:05:11 +0000 Received: from [10.0.1.2] (c-24-61-199-96.hsd1.nh.comcast.net[24.61.199.96]) by comcast.net (rwcrmhc14) with SMTP id <2005061818050801400bat2le>; Sat, 18 Jun 2005 18:05:09 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 18 Jun 2005 18:05:00 -0000 Subject: Re: basic VRP min/max range overflow question From: Paul Schlie To: "Joseph S. Myers" CC: Dale Johannesen , Robert Dewar , Mike Stump , Andrew Pinski , GCC Development Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-06/txt/msg00749.txt.bz2 Sorry, yes the quote below defines unspecified, not undefined behavior. Now more correctly: [#1] Behavior, upon use of a nonportable or erroneous program construct, of erroneous data, or of indeterminately valued objects, for which this International Standard imposes no requirements. Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). [#3] The implementation must successfully translate a given program unless a syntax error is detected, a constraint is violated, or it can determine that every possible execution of that program would result in undefined behavior. Which again is specific to that which is defined, as it requires the successful (and presumably conformant) translation of the program unless the implementation can prove the whole program is itself would have an undefined behavior (reinforcing the notion that the language's semantics remain in force even in the presence of a expression with undefined semantics). > From: Paul Schlie >> From: "Joseph S. Myers" >> On Sat, 18 Jun 2005, Paul Schlie wrote: >> >>> Maybe I didn't phrase my statement well; I fully agree with the cited >>> paragraph above which specifically says a program containing unspecified >>> behavior "shall be a correct program and act in accordance with >>> 5.1.2.3". Which specifies program execution, in terms of an abstract machine >>> model, which correspondingly requires: >> >> You appear to have confused unspecified behavior (where the possibilities >> are bounded) and undefined behavior (where the possibilities are >> unbounded). On *undefined* behavior (such as signed integer overflow), >> *this International Standard imposes no requirements*. If a program >> execution involved undefined behavior, *there are no requirements on its >> execution, even before the undefined behavior occurs in the abstract >> machine*. > > No, the standard clearly states that it imposes no requirements on the > behavior which an implementation may choose to implement for (and limited to) > that specific undefined behavior; as regardless of that behavior, it's > resulting side effects clearly remains constrained by the rules as specified > in 5.1.2.3. > > [#1] Behavior where this International Standard provides two > or more possibilities and imposes no requirements on which > is chosen in any instance. A program that is correct in all > other aspects, operating on correct data, containing > unspecified behavior shall be a correct program and act in > accordance with subclause 5.1.2.3. > >> Therefore the compiler assumes that you only ever pass it >> programs which do not execute undefined behavior. If a possible execution >> might involve undefined behavior, the compiler presumes that the >> programmer knows more than it can prove and knows that the relevant >> circumstances cannot arise at execution. > > The compiler is free to presume whatever it desires as long as the evaluation > of the resulting code it produces conforms to the requirements of the > language. Therefore any compiler which does not consistently treat the side > effects (if any) resulting from the evaluation of an undefined behavior past > the sequence points logically bounding that behavior is non-conformant. > >> For example, a correct program >> never involves overflow of a signed loop variable, so the compiler >> presumes that the programmer proved that the loop variable can never >> overflow at execution and uses this information to optimize the loop: it >> cannot prove it by itself but using the presumption that the program is >> correct it can optimize the program better. > > As program which may specify/invoke an undefined behavior remains a correct, > albeit non-portable and even possibly indeterminate, program; its arguably > incorrect for a compiler to presume otherwise, however is free to choose > an arbitrary behavior for any specified undefined behaviors specified in the > code, but remains bound to consistently treat the resulting side-effects of > whatever behavior it choose to implement in the evaluation of the program past > the sequence point those side-effects remain bound by. > > Therefore, given your example; regardless of what value an implementation > chooses to logically assign to an overflowed loop iteration variable, the > compiler can't assume it's X for the purposes of optimization when in fact it > was assigned the value Y past the sequence point that operation remains > bounded by, as this would violate the sequence rule semantics imposed on all > expression evaluations, regardless of their individual semantics, and possibly > result in non-conformant erroneous behavior. > >> The traditional form of undefined behavior is for demons to fly out of >> your nose. We just haven't yet got -fnasal-demons working reliably but it >> would be conforming for it to be on by default. If you are lucky, it will >> happen anyway without that option. > > As long as all side-effects are logically expressed at it's sequence point > bounds, I've got no problem with this :)