From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2758 invoked by alias); 20 Jun 2005 13:01:20 -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 2009 invoked by uid 22791); 20 Jun 2005 13:00:38 -0000 Received: from sccrmhc11.comcast.net (HELO sccrmhc11.comcast.net) (204.127.202.55) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 20 Jun 2005 13:00:38 +0000 Received: from [10.0.1.2] (c-24-61-199-96.hsd1.nh.comcast.net[24.61.199.96]) by comcast.net (sccrmhc11) with SMTP id <2005062013003401100s5em0e>; Mon, 20 Jun 2005 13:00:35 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 20 Jun 2005 13:01:00 -0000 Subject: Re: basic VRP min/max range overflow question From: Paul Schlie To: Robert Dewar CC: Michael Veksler , Dale Johannesen , GCC Development , "Joseph S. Myers" , Mike Stump , Andrew Pinski Message-ID: In-Reply-To: <42B6B8CC.5090902@adacore.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-06/txt/msg00891.txt.bz2 > From: Robert Dewar >> Paul Schlie wrote: > >> - You may be correct, although it's not obviously the case? (As requiring >> all undefined behavior be encapsulated between sequence points already >> seems implied to me, as I don't see any explicit counter examples >> requiring otherwise. > > There don't need to be examples. The as-if rule always applies, if you cannot > write a legitimate C program that shows the difference between two possible > implementations, then both are correct. ??? as-if means they're logically equivalent (i.e. there is no logical difference between the two alternative representations, and strongly support that this should be the guideline for all optimizations). > Note that the requirement of a > legitimate C program exlude ANY program which has undefined behavior anywhere. Then it is illegitimate for a compiler to generate a program which contains a known undefined behavior, (i.e. any known overflow, any unsigned to signed cast which is known to not be representable, any pointer dereference of a known null value, etc.; rather than generate any code.) >> Nor do any optimizations which are obviously more >> useful than potentially counterproductive seem to require the violation of >> C's sequence point semantics?) > > Ordinary code motion optimizations like hoisting out of a loop are an obvious > example, there are lots of others. If you read the dragon book (are you > familiar with this book?) then almost all optimizations discussed there in the > global optimization chapters would be affected. Expression reordering does not necessitate the violation of sequence point semantics as long as at the last point of reordering, the resulting semantics are logically equivalent (as-if); which is why it's a safe optimization if the logical behavior is preserved.