From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11322 invoked by alias); 20 Jun 2005 11:32:25 -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 11228 invoked by uid 22791); 20 Jun 2005 11:31:49 -0000 Received: from morbo.e-centre.net (HELO cubert.e-centre.net) (66.154.82.3) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 20 Jun 2005 11:31:49 +0000 Received: from [10.3.1.19] (helo=guestrelay.stayonline.net) by cubert.e-centre.net with esmtp (Exim 4.50) id 1DkKVA-0008Rq-T6; Mon, 20 Jun 2005 07:31:41 -0400 Received: from [127.0.0.1] (unknown [12.43.112.130]) by guestrelay.stayonline.net (Spam Firewall) with ESMTP id 072F72003847; Mon, 20 Jun 2005 07:31:38 -0400 (EDT) Message-ID: <42B6A90E.9030804@adacore.com> Date: Mon, 20 Jun 2005 11:32:00 -0000 From: Robert Dewar User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) MIME-Version: 1.0 To: Paul Schlie CC: Michael Veksler , Dale Johannesen , GCC Development , "Joseph S. Myers" , Mike Stump , Andrew Pinski Subject: Re: basic VRP min/max range overflow question References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-06/txt/msg00881.txt.bz2 Paul Schlie wrote: > As in my mind, the semantics of foo() dictate that it print the value of > the storage location which was allocated to the variable "a", where unless > "a" is initialized with an explicit value, may be arbitrary. So I've got no > problem with arbitrary results or behavior, I just simply believe they are > implicitly constrained to the remaining rules of the language, i.e. all > side-effects must be expressed upon reaching a sequence point which > logically bounds the effects of the evaluation of any expression. This cannot be formalized, and is not what the standard says. The fact that you believe it is interesting (though I don't think you can write a formal description of what you believe in C standard terms), but we operate by what the standard formally says, not by what one person informally believes. > > (where if an undefined behavior it did delete the program being executed it > wouldn't resume execution beyond the next sequence point, but if it does, it > must continue to abide by the languages rules regardless of the resulting > side effects from the preceding behaviors) Sequence points simply do not have this semantics. If they did, then nearly all useful optimizations would be prohibited. You are essentially positing a model in which the state at every sequence point is not only defined by the standard, but must be reflected in the implementation with no use of as-if semantics. I don't see this as meaningful, and I don't think this can be formalized. I am quite *sure* that it is undesirable.