From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30575 invoked by alias); 20 Jun 2005 14:54:46 -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 30403 invoked by uid 22791); 20 Jun 2005 14:54:23 -0000 Received: from mtagate3.de.ibm.com (HELO mtagate3.de.ibm.com) (195.212.29.152) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 20 Jun 2005 14:54:23 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id j5KEsLmf206172 for ; Mon, 20 Jun 2005 14:54:21 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j5KEsKTS103038 for ; Mon, 20 Jun 2005 16:54:20 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j5KEsJUc029817 for ; Mon, 20 Jun 2005 16:54:20 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j5KEsIBj029804; Mon, 20 Jun 2005 16:54:18 +0200 In-Reply-To: Subject: Re: basic VRP min/max range overflow question To: Paul Schlie Cc: Dale Johannesen , Robert Dewar , GCC Development , "Joseph S. Myers" , Mike Stump , Andrew Pinski Message-ID: From: Michael Veksler Date: Mon, 20 Jun 2005 14:54:00 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-SW-Source: 2005-06/txt/msg00903.txt.bz2 Paul Schlie wrote on 20/06/2005 16:09:16: > > From: Michael Veksler > > > As for overflow, you can say that you want instead of "undefined" > > to treat is "unspecified". Where each architecture / opsys / compiler > > must consistently define what happens on overflow: > > - saturation > > - wrap 2's (or 1's) complement > > - exception. > > - yes, effectively I don't perceive any necessity for undefined, vs > unspecified; as I don't perceive any necessity to give the compiler > the freedom to treat generate an arbitrary program which may contain > a potentially ambiguous specific and isolatable behavior. Again, is > seems real simple to abide by C's sequence point and as-if rules to contain > any ambiguity to the bounds between it's logical sequence points, and any > resulting side-effects specific to that ambiguity must be expressed and > logically bounded there. Look again at my dangling pointer example. In this example, the most benign optimizations may "generate an arbitrary program" in this case. As I said, and as Robert Dewar concurred, you can carefully define something less strict than "undefined" on a case by case basis. On the other hand, it is impossible to make all "undefined" cases demonstrate an "isolatable behavior". Such a broad requirement is impossible to fulfill, as my dangling pointer example shows. > > > You can argue (and maybe show benchmarks) that the above > > "unspecified" does not inhibit too many real world optimizations, > > as compared with "undefined". If that were the case, you would > > have a chance convincing the std and gcc of your views. > > - can one show that it is unreasonable? Someone will have to prove it first. Just waving hands will convince nobody. Maybe if you are lucky, you may convince somebody to make an experiment, that in the end may or may not lead to changes in gcc or the std. > > > However, generalizing things for all "undefined behavior" is > > doomed to failure. Not all "undefined behaviors" were born equal, > > and you can't treat them as equal, unless they > > "enable the compiler to do anything". > > - example? Again, the dangling pointer example. Dangling pointer may or may not lead to the corruption of the code itself (self modifying code). When that inadvertently happens, all bets are off. It is possible that by pure luck the code is "safe" without optimization, and after optimizing unrelated stuff the code becomes self destructive. This is one of the cases of "undefined" behavior that cannot be reasonably bounded. Would you like to sub-categorize "undefined" to get rid of cases like the dangling pointer? Are you willing to make sure that they are OK? Again, this is a nontrivial task to get right. You can't get it simply by disabling optimization X or fixing optimization Y. This is out of the scope of this list. This list is not intended to discuss and define new language semantics. You will have to either come up with a reasonable definition yourself, or get help from experts in the field. And only then go to the std or gcc. I have been burnt by these issues too many times exactly because I am not an expert in the field, I am still learning. You too should try to be more cautious in the treacherous realm of language specification. Are you sure you want to go there? Michael