From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10559 invoked by alias); 26 Jan 2007 19:21:00 -0000 Received: (qmail 10551 invoked by uid 22791); 26 Jan 2007 19:20:59 -0000 X-Spam-Check-By: sourceware.org Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 26 Jan 2007 19:20:52 +0000 Received: from relay8.apple.com (a17-128-113-38.apple.com [17.128.113.38]) by mail-out4.apple.com (8.13.8/8.13.8) with ESMTP id l0QJJk1o016665; Fri, 26 Jan 2007 11:19:46 -0800 (PST) Received: from relay8.apple.com (unknown [127.0.0.1]) by relay8.apple.com (Symantec Mail Security) with ESMTP id 5525A4004C; Fri, 26 Jan 2007 11:19:46 -0800 (PST) X-AuditID: 11807126-a2682bb000000245-3d-45ba54526c97 Received: from [17.219.213.137] (unknown [17.219.213.137]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay8.apple.com (Apple SCV relay) with ESMTP id 253184008B; Fri, 26 Jan 2007 11:19:46 -0800 (PST) In-Reply-To: <10701261319.AA21003@vlsi1.ultra.nyu.edu> References: <200701061422.39157.ebotcazou@adacore.com> <45B63E9B.9090909@codesourcery.com> <84fc9c000701230924g37ed4f42vca8d7ae0c1ef6e52@mail.gmail.com> <45B6643C.6000800@codesourcery.com> <84fc9c000701231257u7fb1f10rdd3255be8aa69686@mail.gmail.com> <10701240137.AA23316@vlsi1.ultra.nyu.edu> <84fc9c000701240127x2fe9492bq355cd35260e7b55e@mail.gmail.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> <10701261319.AA21003@vlsi1.ultra.nyu.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: ebotcazou@adacore.com, gcc-patches@gcc.gnu.org, mark@codesourcery.com, richard.guenther@gmail.com Content-Transfer-Encoding: 7bit From: Mike Stump Subject: Re: [PATCH] Tree SRA and atomicity/volatility Date: Fri, 26 Jan 2007 19:21:00 -0000 To: Richard Kenner X-Mailer: Apple Mail (2.752.2) 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/msg02205.txt.bz2 On Jan 26, 2007, at 5:19 AM, Richard Kenner wrote: > I think the point here is that writing it down at the level you > suggested You read way to much into it, if you look again, I didn't state that we should overspecify it, I said that we had the freedom to talk about chipset, if we waned to. A language standard cannot. A compiler implementation can, if it _wants_ to, if it _needs_ to. Again, let me repeat, I'm not arguing that it needs to. Let me give you an example, let's say that we have two volatile objects and an operation to perform on them. Let's say the machine we're generating code for doesn't have that operation, but that it can be decomposed into smaller operations. We are free to document the backend must not decompose the operation and leave the volatile objects as operands. Or, we are free to leave it unspecified. Ada might even have a mandate here. C might as well. I don't think I've seen it argued here if decomposition is allowed or not. Now, this might be so trivial to those in the know that can't believe anyone would get something so basic wrong, and yet, I can see an expander for an operation split things up, fail to check for volatile. The documentation would be so that people that might not know the answer to read it once, and then have a firm, specific grasp on the subject matter so that to them it is then perfectly clear decomposition is wrong, obvious if you will.