From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14121 invoked by alias); 24 Jan 2007 13:02:23 -0000 Received: (qmail 14080 invoked by uid 22791); 24 Jan 2007 13:02:19 -0000 X-Spam-Check-By: sourceware.org Received: from VLSI1.ULTRA.NYU.EDU (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sourceware.org (qpsmtpd/0.31) with SMTP; Wed, 24 Jan 2007 13:01:58 +0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA01425; Wed, 24 Jan 07 08:07:33 EST From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10701241307.AA01425@vlsi1.ultra.nyu.edu> Date: Wed, 24 Jan 2007 13:02:00 -0000 To: richard.guenther@gmail.com Subject: Re: [PATCH] Tree SRA and atomicity/volatility Cc: ebotcazou@adacore.com, gcc-patches@gcc.gnu.org, mark@codesourcery.com In-Reply-To: <84fc9c000701240127x2fe9492bq355cd35260e7b55e@mail.gmail.com> 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> 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/msg01990.txt.bz2 > I would suggest specifying TYPE_VOLATILE on a structure type as matching > behavior with TYPE_VOLATILE on a bitfield with the same machine mode. I don't follow. TYPE_VOLATILE on a bitfield seems to be the *least* well-defined to me. For a non-bitfield, we all understand what the "natural" access to that field or variable should be, so volatile says "always do that access". But what's the "natural" access to a bitfield that we are to preserve? > So, if you can set TYPE_MODE of the structure to SImode (as in Erics original > example) volatile on the strucutre should behave as if it were an SImode > bitfield (or integer). Sure: that's the same as for a scalar. > So if you can only use BLKmode on the structure it's either invalid > or undefined what happens. I see *all* of these semantics of volatile as undefined from a formal point of view. When you set it on BLKmode, obviously you're asking for less, but the generic principle of doing the least changes still applies. For example, a copy of an entire structure should access each byte of memory exactly once (which rules out field-by-field copies of structures that contain bitfields). > This would of course force more "whole aggregate" access than appearantly > required by the language, for example forcing read-modify-write cycles for > structure component access rather than just forcing whole aggregate access > for whole aggregate copy (which doesn't sound too useful on its own). I don't follow. I still don't understand why it's necessary or useful to try to define these semantics more precisely. Traditionally, "volatile" has simply meant to do as little mucking around with accesses to volatile objects as possible. That's also the easiest implementation. I don't understand what problem you are trying to solve.