From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10097 invoked by alias); 12 Jan 2007 16:36:59 -0000 Received: (qmail 10082 invoked by uid 22791); 12 Jan 2007 16:36:58 -0000 X-Spam-Check-By: sourceware.org Received: from ug-out-1314.google.com (HELO ug-out-1314.google.com) (66.249.92.172) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 12 Jan 2007 16:36:53 +0000 Received: by ug-out-1314.google.com with SMTP id s2so785549uge for ; Fri, 12 Jan 2007 08:36:51 -0800 (PST) Received: by 10.82.139.17 with SMTP id m17mr156076bud.1168619810709; Fri, 12 Jan 2007 08:36:50 -0800 (PST) Received: by 10.82.150.13 with HTTP; Fri, 12 Jan 2007 08:36:50 -0800 (PST) Message-ID: <84fc9c000701120836r5cfd514fqdfcbd7addccb2ec@mail.gmail.com> Date: Fri, 12 Jan 2007 16:36:00 -0000 From: "Richard Guenther" To: "Eric Botcazou" Subject: Re: [PATCH] Tree SRA and atomicity/volatility Cc: gcc-patches@gcc.gnu.org In-Reply-To: <200701121500.12161.ebotcazou@adacore.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> <84fc9c000701080352x517b891cva220bc67f75a2a06@mail.gmail.com> <84fc9c000701080654k213b1912gd0f741b0899815d4@mail.gmail.com> <200701121500.12161.ebotcazou@adacore.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/msg01092.txt.bz2 On 1/12/07, Eric Botcazou wrote: > [Sorry for the delay, pretty hot week] > > > On a second thought this cannot be true. If you have "all the magic > > to support atomicity" and generate "the full-word access on" your own -- > > why do you expose the individual fields to the middle-end at all?? > > Well, the type has fields and you can access these fields individually in the > source so they must be present in the IL to generate debug info for them. > > > I claim you _cannot_ generate full-word access this way (unless > > using memcpy, but even that is nowadays lowered). > > Do not underestimate the cleverness of Gigi. :-) I don't see anything "clever" in Q () { typedef q__byte q__byte; typedef struct q__word q__word; struct q__word T1b = {.first=0, .second=0, .third=0, .fourth=0}; struct q__word tmp; struct q__word external = VIEW_CONVERT_EXPR(SAVE_EXPR ); tmp = VIEW_CONVERT_EXPR(external); tmp.first = 0; external = VIEW_CONVERT_EXPR(tmp); return; } for this testcase (t02.original dump, gcc 4.1.2) . Now if I change the testcase to something I requested (direct write to a component), I get Q () { typedef q__byte q__byte; typedef struct q__word q__word; struct q__word T1b = {.first=0, .second=0, .third=0, .fourth=0}; struct q__word external = VIEW_CONVERT_EXPR(SAVE_EXPR ); VIEW_CONVERT_EXPR(external).first = 0; return; } and after gimplification we can see all it broken already (that is, you exposed the component write to the middle-end - no cleverness prevented this): Q () { struct q__word T1b.0; typedef q__byte q__byte; typedef struct q__word q__word; struct q__word T1b; struct q__word external; T1b.first = 0; T1b.second = 0; T1b.third = 0; T1b.fourth = 0; T1b.0 = T1b; external = T1b.0; external.first = 0; return; } The testcase now looks like: procedure Q is type Byte is mod 2**8; for Byte'Size use 8; type Word is record First, Second, Third, Fourth : Byte; end record; External : Word := (others => 0); pragma Atomic (External); begin External.First := 0; end; > > So get us a testcase that shows copy/read/write on elements of such > > a type. > > Direct translation of the C testcase attached. At -O2 -fno-tree-sra on i686: Assembler is of course not interesting - interesting is what gigi feeds the middle-end with - and that part certainly ensures no such thing as atomic access. Richard.