From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32114 invoked by alias); 28 Jun 2005 17:41:41 -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 32103 invoked by uid 22791); 28 Jun 2005 17:41:37 -0000 Received: from sccrmhc13.comcast.net (HELO sccrmhc13.comcast.net) (204.127.202.64) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 28 Jun 2005 17:41:37 +0000 Received: from [10.0.1.2] (c-24-61-199-96.hsd1.nh.comcast.net[24.61.199.96]) by comcast.net (sccrmhc13) with SMTP id <2005062817413401600jegrte>; Tue, 28 Jun 2005 17:41:35 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 28 Jun 2005 17:41:00 -0000 Subject: Re: signed is undefined and has been since 1992 (in GCC) From: Paul Schlie To: Gabriel Dos Reis , Steven Bosscher , Robert Dewar , Andrew Pinski CC: GCC Development Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-06/txt/msg01159.txt.bz2 Gabriel Dos Reis writes: > Steven Bosscher writes: >| On Tuesday 28 June 2005 07:12, Gabriel Dos Reis wrote: >| > For the concrete case at issue, if the hardware I'm writing the C/C++ >| > programs for consistently displays modulo arithmetics for signed >| > integer type, Andrew can you tell me why GCC should deny me access >| > to that functionally where it actually can? >| >| Because it disallows compiler transformations? E.g. suddenly a >| loop with a signed variable as the loop counter may wrap around, >| which that means some transformations that are safe now would >| no longer be safe. > > You have to define "safe". Obviously, if you make the assumption that > with signed overflow, all bets are off then you can go to > tansformations predicated by that assumption. If you take the > assumption that signed overflow is defined and supported, you can go > transformations predicated by that assumption. In either case, "safe" > is with respect to the semantics chosen. Yes. Overall the problem/conflict seems to revolve around the differentiation between what's allowed vs. should be done; where "should" is of course subjective, so it may be worth first attempting to define philosophically what an idealized implementation "should" do, and then strive to follow this guideline in cases where the compiler has the freedom to do so. For what it's worth, a compiler "should": - Strictly implement all mandated language semantics by default; although may enable these semantics to be extended and/or altered, if believed to be "Most Likely Beneficial", only by explicit request to do so. - Define and correspondingly strictly implement the "Most Likely Beneficial" semantics which are not mandated by the standard as if they were, and emit a warning for every such behavior which is known to likely to express itself. (i.e. a shift by a value known to have a range which may exceed the size of it's shifted operand, or a the dereference of a pointer which is known to potentially be NULL, for example.) - Where the "Most likely Beneficial" semantics are those which most likely: - improve the expressiveness and/or consistency of the language. - improve the determinism of the language and resulting executable. - improve the efficiency of the language and resulting executable by adopting and basing optimizations on the target's native semantics when not in conflict with the above. Thereby it's never "Most likely Beneficial" to base optimizations on a presumed undefined behavior, as no such behaviors should exist; therefore such optimizations will only likely yield inconsistent and/or potentially non-deterministic results, which is most likely not beneficial toward the goals of producing an efficient deterministic program. (The key to an efficient, consistent, and deterministic compiled program is leveraging the natural behavior of the target where it is not in conflict with the language's or implementation's otherwise defined semantics.)