From patchwork Tue Oct 26 06:59:30 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jie Zhang X-Patchwork-Id: 69180 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id F3E60B70A9 for ; Tue, 26 Oct 2010 17:59:38 +1100 (EST) Received: (qmail 28094 invoked by alias); 26 Oct 2010 06:59:36 -0000 Received: (qmail 28086 invoked by uid 22791); 26 Oct 2010 06:59:35 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL, BAYES_00, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 26 Oct 2010 06:59:31 +0000 Received: (qmail 21239 invoked from network); 26 Oct 2010 06:59:29 -0000 Received: from unknown (HELO ?192.168.1.106?) (jie@127.0.0.2) by mail.codesourcery.com with ESMTPA; 26 Oct 2010 06:59:29 -0000 Message-ID: <4CC67C52.5000905@codesourcery.com> Date: Tue, 26 Oct 2010 14:59:30 +0800 From: Jie Zhang User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100918 Icedove/3.1.4 MIME-Version: 1.0 To: gcc-patches@gcc.gnu.org, Richard Kenner , Mark Mitchell Subject: [doc] Improve documentation of -fstrict-volatile-bitfields X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org This patch replaces "container's type" with "field's type". "Container" is confusing. It could be interpreted as the structure containing the bit-fields. It also documents the recent change I made to -fstrict-volatile-bitfields, i.e. packed attribute takes preference when it conflicts with -fstrict-volatile-bitfields because of strict alignment. Is it OK? * doc/invoke.texi: Improve documentation of -fstrict-volatile-bitfields. Index: doc/invoke.texi =================================================================== --- doc/invoke.texi (revision 165935) +++ doc/invoke.texi (working copy) @@ -18120,8 +18120,8 @@ @opindex fstrict-volatile-bitfields This option should be used if accesses to volatile bitfields (or other structure fields, although the compiler usually honors those types -anyway) should use a single access in a mode of the same size as the -container's type, aligned to a natural alignment if possible. For +anyway) should use a single access of the width of the +field's type, aligned to a natural alignment if possible. For example, targets with memory-mapped peripheral registers might require all such accesses to be 16 bits wide; with this flag the user could declare all peripheral bitfields as ``unsigned short'' (assuming short @@ -18134,9 +18134,11 @@ any portion of the bitfield, or memory-mapped registers unrelated to the one being updated. -If the target requires strict alignment, and honoring the container +If the target requires strict alignment, and honoring the field type would require violating this alignment, a warning is issued. -However, the access happens as the user requested, under the +If the field has @code{packed} attribute, the access happens without +honoring the field type. If the field doesn't have @code{packed} +attribute, the access happens honoring the field type. Both are under the assumption that the user knows something about the target hardware that GCC is unaware of.