From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2252 invoked by alias); 28 Jun 2005 09:18: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 2194 invoked by uid 22791); 28 Jun 2005 09:18:16 -0000 Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 28 Jun 2005 09:18:16 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id E2B25963D; Tue, 28 Jun 2005 05:18:14 -0400 (EDT) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 27573-01-6; Tue, 28 Jun 2005 05:18:14 -0400 (EDT) Received: from [127.0.0.1] (taconic.gnat.com [205.232.38.103]) by nile.gnat.com (Postfix) with ESMTP id B35169639; Tue, 28 Jun 2005 05:18:14 -0400 (EDT) Message-ID: <42C115D5.8070503@adacore.com> Date: Tue, 28 Jun 2005 09:18:00 -0000 From: Robert Dewar User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) MIME-Version: 1.0 To: Gabriel Dos Reis CC: Andrew Pinski , gcc mailing list Subject: Re: signed is undefined and has been since 1992 (in GCC) References: <27fdc0d8dc588cfdb3a14a153c5d037c@physics.uc.edu> <6d9fa260f233e519762c7d11276a35ad@physics.uc.edu> <3dbad9a6bd7eb1aea74ff2245eaa1b99@physics.uc.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-06/txt/msg01086.txt.bz2 Gabriel Dos Reis wrote: > and it should also be able to take your life. Do you want it to actually > do it? If yes, I suggest you create your own compiler that does that > and leave us work on a compiler that does something more positive. > > -- Gaby Obviously no one programs a compiler to deliberately have disastrous behavior in an undefined situation. However, if you are interested in the best possible code from an efficiency point of view, the compiler is allowed to assert that the overflow cannot take place, and then make all logical deductions about control flow etc that come from this assumption. As I showed with my password example, this can have unexpected results. The standard allows this broad view of undefined precisely so that undefined behavior does not damage generated code quality. Of course a compiler is free to take a much narrower view of undefined, but this should be done with some clear knowledge of the trade offs in terms of damaging code efficiency. I do think that the Ada 95 approach of replacing undefined behavior (called erroneous execution in Ada) with the notion of a bounded error is a good one. This allows the effects to be bounded without any undue effect on quality of code. The forward and backward propagation of the assumption of no undefined behavior can indeed have surprising effects, and as compiler optimizers get more sophisticated and more global, the effects become more unbounded. Informally I think you would like to say something like "no backward propagation at all, and no forward propagation if it causes results that are too surprising to the user", but even the first part of this is very difficult to formalize, and the second part is impsosible to formalize.