From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25592 invoked by alias); 15 Nov 2012 12:25:37 -0000 Received: (qmail 25574 invoked by uid 22791); 15 Nov 2012 12:25:32 -0000 X-SWARE-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00,DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,KHOP_RCVD_TRUST,NML_ADSP_CUSTOM_MED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-bk0-f47.google.com (HELO mail-bk0-f47.google.com) (209.85.214.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 15 Nov 2012 12:25:28 +0000 Received: by mail-bk0-f47.google.com with SMTP id jk7so672138bkc.20 for ; Thu, 15 Nov 2012 04:25:27 -0800 (PST) Received: by 10.204.150.220 with SMTP id z28mr319818bkv.125.1352982327306; Thu, 15 Nov 2012 04:25:27 -0800 (PST) Received: from sandifor-thinkpad.stglab.manchester.uk.ibm.com (gbibp9ph1--blueice1n1.emea.ibm.com. [195.212.29.67]) by mx.google.com with ESMTPS id fm5sm10061833bkc.5.2012.11.15.04.25.25 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Nov 2012 04:25:26 -0800 (PST) From: Richard Sandiford To: Eric Botcazou Mail-Followup-To: Eric Botcazou ,gcc-patches@gcc.gnu.org, rdsandiford@googlemail.com Cc: gcc-patches@gcc.gnu.org Subject: Re: [6/8] Add strict volatile handling to bit_field_mode_iterator References: <87k3u3eybu.fsf@talisman.home> <87txt7dix7.fsf@talisman.home> <1775073.QASfiHdzOH@polaris> Date: Thu, 15 Nov 2012 12:25:00 -0000 In-Reply-To: <1775073.QASfiHdzOH@polaris> (Eric Botcazou's message of "Tue, 13 Nov 2012 14:56:05 +0100") Message-ID: <87fw4bvyrv.fsf@sandifor-thinkpad.stglab.manchester.uk.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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: 2012-11/txt/msg01229.txt.bz2 Thanks for the reviews. Eric Botcazou writes: >> This patch makes bit_field_mode_iterator take -fstrict-volatile-bitfields >> into account, in cases where the size of the underlying object is known. >> This is used in the next patch. > > Do we really need to add that to the iterator? The -fstrict-volatile- > bitfields implementation is still controversial so I'm not sure that we want > let it spread. Can't the client code just skip the problematic modes? The idea was to centralise the knowledge about what modes are valid rather than requiring every client to know the rules. From that point of view it seems inconsistent for the new interface to handle the bitregion_{start,end} restrictions (a correctness issue) but not the volatility restrictions (also a correctness issue). Especially when the interface already knows whether the field is volatile and already handles the choice between "narrow" and "wide" volatile bitfields. If there's talk of removing -fstrict-volatile or changing its semantics then handling it in the interface ought to make that easier. Richard