From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1080 invoked by alias); 26 Jan 2007 09:17:32 -0000 Received: (qmail 1068 invoked by uid 22791); 26 Jan 2007 09:17:31 -0000 X-Spam-Check-By: sourceware.org Received: from nf-out-0910.google.com (HELO nf-out-0910.google.com) (64.233.182.186) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 26 Jan 2007 09:17:27 +0000 Received: by nf-out-0910.google.com with SMTP id a25so1081204nfc for ; Fri, 26 Jan 2007 01:17:24 -0800 (PST) Received: by 10.82.111.8 with SMTP id j8mr1705942buc.1169803044242; Fri, 26 Jan 2007 01:17:24 -0800 (PST) Received: by 10.82.150.13 with HTTP; Fri, 26 Jan 2007 01:17:24 -0800 (PST) Message-ID: <84fc9c000701260117x7ec2e0e1p71cf64ea4d35deb9@mail.gmail.com> Date: Fri, 26 Jan 2007 09:17:00 -0000 From: "Richard Guenther" To: "Mark Mitchell" Subject: Re: [PATCH] Tree SRA and atomicity/volatility Cc: "Mike Stump" , "Richard Kenner" , ebotcazou@adacore.com, gcc-patches@gcc.gnu.org In-Reply-To: <45B96D42.5010303@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200701061422.39157.ebotcazou@adacore.com> <10701241307.AA01425@vlsi1.ultra.nyu.edu> <84fc9c000701240533p217a2735i8e42634e07029df7@mail.gmail.com> <45B7A5E8.3080102@codesourcery.com> <84fc9c000701250138s26cd7932oc00a139c7c321898@mail.gmail.com> <10701251144.AA24290@vlsi1.ultra.nyu.edu> <6FECE966-A8EB-4AC9-8677-48354D50A73B@apple.com> <45B96954.9080305@codesourcery.com> <45B96D42.5010303@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-01/txt/msg02176.txt.bz2 On 1/26/07, Mark Mitchell wrote: > Mike Stump wrote: > > On Jan 25, 2007, at 6:37 PM, Mark Mitchell wrote: > >> But, once you write it down, you get to figure out how to make sure that > >> the entire compiler honors it, including the machine-independent > >> TREE-SSA bits. Since the sensible choices may be different for each > >> CPU, how to enforce the right constraints (either separately for each > >> CPU, or some superset of all of them) may not be easy. > > > > Well, you know not writing it down doesn't absolve us from having to get > > it right anyway. I'd further say that writing it does should not > > constrain us from fixing the wording if the wording is broken, but I > > agree, if we write it down, it would be better to have the right > > theoretic answer and leave unspecified those bits that should be. > > If we make promises and don't keep them, users might be angry. If we > don't make promises, they may be disappointed by the fuzziness, but at > least we're not tricking them. I see that Ada _does_ make promises to the user. And I see the Ada frontend tries to fulfill these promises by relying on the middle-end not mucking up with TYPE_VOLATILE structs. (And to my surprise it somehow works to some degree) I'd like to have those bits that the middle-end can reasonably guarantee specified - this will be a stricter better situation than what we have now. I _don't_ suggest to put this anywhere in user documentation to suggest we're promising anything on a C volatile struct type. But I want to nail down as much as possible of the GCC frontend - middle-end interface. As we happen to have (at least) one language that GCC supports that has a somewhat strict and reasonable specification about a sort-of volatileness we better make sure we can map this somehow to the middle-end. > I'm in no way opposed to specifying exactly what "volatile" means on an > i686 CPU, but I think it's hard to specify and hard to implement. Prove > me wrong, by all means! > > I would hope that we could all agree that (a) specifying the behavior in > detail would be nice, but (b) absent a specification, fixing issues on a > case-by-case basis is reasonable. It's a fallacy to argue that just > because I'm arguing for (b) that I'm opposed to a middle-end type > system, don't want to specify behavior. > > I just want to make the compiler better, step by step, and the step > right in front of us is Eric's patch, which everyone agrees improves > things, modulo, perhaps, exactly how it's implement. So, let's get the > patch in, and move on. When someone wants to invest the effort in the > full specification, implementation, test cases, etc., we can do that, > but that shouldn't stop us fixing the current problem. I disagree. We have a defect for Ada and Ada happens to require certain semantics on a for now unspecified middle-end construct. It is perfectly reasonable to require, that upon fixing this defect, the interface between the frontend and middle-end is specified where it relates to that defect. And I still request that the Ada folks come up with a sentence or two for that. It would have been all done in the time we're discussing here. Richard.