From patchwork Sun Nov 11 02:51:23 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sandra Loosemore X-Patchwork-Id: 198233 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 915C22C0084 for ; Sun, 11 Nov 2012 13:52:31 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1353207154; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:Sender:Delivered-To; bh=HPfoCET s4JAR+TVAzjvCq+cjUKE=; b=aMlZTkV90YglrcwsW3cwJF/6RMxgel2XoNkPEOR Fd5AbVWQeXWS+bpkya4+PJFkn6+HYF7MrRBvbGi1MEgLAR6Pj3w3j/XXWy4DcoQn 4FmSPdhmbrCVHS3lSUWrxO4QZO7rnq+EzNldyGczI+otj3NYOIGRSYTp8rK/JgfO b3rc= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=eT7CxhxRLnS9vf1sS5d7gMa81M1kXYafqBKcU9L39t3vGS/+Q2ddjbcnIq76fK 56Dmxqw7Ee1AYghpCyV51gu47m2Yt3JDi9YlB6ZgJkK9gbqZ0NFA8vpSarZQNLhl B6O0mBHJbzPOWrGyUSjyji09f0pI94bXhW5283BoQBERA=; Received: (qmail 2436 invoked by alias); 11 Nov 2012 02:52:26 -0000 Received: (qmail 2427 invoked by uid 22791); 11 Nov 2012 02:52:25 -0000 X-SWARE-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, RCVD_IN_HOSTKARMA_W, RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 11 Nov 2012 02:52:20 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1TXNek-0003iT-5u from Sandra_Loosemore@mentor.com for gcc-patches@gcc.gnu.org; Sat, 10 Nov 2012 18:52:18 -0800 Received: from SVR-ORW-FEM-04.mgc.mentorg.com ([147.34.97.41]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 10 Nov 2012 18:52:18 -0800 Received: from [IPv6:::1] (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.1.289.1; Sat, 10 Nov 2012 18:52:16 -0800 Message-ID: <509F12AB.4030605@codesourcery.com> Date: Sat, 10 Nov 2012 19:51:23 -0700 From: Sandra Loosemore User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Subject: [doc] extend.texi copy-editing, 4/N (bit-fields) 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 I've checked in this patch to consistently use "bit-field" in extend.texi instead of "bitfield" or "bit field". "Bit-field" is listed in the GCC Coding Conventions as the preferred terminology, for consistency with the C and C++ standards. -Sandra 2012-11-10 Sandra Loosemore gcc/ * doc/extend.texi: Copy-edit to use "bit-field" consistently instead of "bitfield" or "bit field". Index: gcc/doc/extend.texi =================================================================== --- gcc/doc/extend.texi (revision 193402) +++ gcc/doc/extend.texi (working copy) @@ -5006,9 +5006,9 @@ Currently @option{-m[no-]ms-bitfields} i compilers to match the native Microsoft compiler. The Microsoft structure layout algorithm is fairly simple with the exception -of the bitfield packing: +of the bit-field packing: -The padding and alignment of members of structures and whether a bit field +The padding and alignment of members of structures and whether a bit-field can straddle a storage-unit boundary @enumerate @@ -5025,19 +5025,19 @@ Every object is allocated an offset so t offset % alignment-requirement == 0 -@item Adjacent bit fields are packed into the same 1-, 2-, or 4-byte allocation -unit if the integral types are the same size and if the next bit field fits +@item Adjacent bit-fields are packed into the same 1-, 2-, or 4-byte allocation +unit if the integral types are the same size and if the next bit-field fits into the current allocation unit without crossing the boundary imposed by the -common alignment requirements of the bit fields. +common alignment requirements of the bit-fields. @end enumerate -Handling of zero-length bitfields: +Handling of zero-length bit-fields: -MSVC interprets zero-length bitfields in the following ways: +MSVC interprets zero-length bit-fields in the following ways: @enumerate -@item If a zero-length bitfield is inserted between two bitfields that -are normally coalesced, the bitfields are not coalesced. +@item If a zero-length bit-field is inserted between two bit-fields that +are normally coalesced, the bit-fields are not coalesced. For example: @@ -5050,12 +5050,12 @@ struct @} t1; @end smallexample -The size of @code{t1} is 8 bytes with the zero-length bitfield. If the -zero-length bitfield were removed, @code{t1}'s size would be 4 bytes. +The size of @code{t1} is 8 bytes with the zero-length bit-field. If the +zero-length bit-field were removed, @code{t1}'s size would be 4 bytes. -@item If a zero-length bitfield is inserted after a bitfield, @code{foo}, and the -alignment of the zero-length bitfield is greater than the member that follows it, -@code{bar}, @code{bar} is aligned as the type of the zero-length bitfield. +@item If a zero-length bit-field is inserted after a bit-field, @code{foo}, and the +alignment of the zero-length bit-field is greater than the member that follows it, +@code{bar}, @code{bar} is aligned as the type of the zero-length bit-field. For example: @@ -5077,18 +5077,18 @@ struct For @code{t2}, @code{bar} is placed at offset 2, rather than offset 1. Accordingly, the size of @code{t2} is 4. For @code{t3}, the zero-length -bitfield does not affect the alignment of @code{bar} or, as a result, the size +bit-field does not affect the alignment of @code{bar} or, as a result, the size of the structure. Taking this into account, it is important to note the following: @enumerate -@item If a zero-length bitfield follows a normal bitfield, the type of the -zero-length bitfield may affect the alignment of the structure as whole. For -example, @code{t2} has a size of 4 bytes, since the zero-length bitfield follows a -normal bitfield, and is of type short. +@item If a zero-length bit-field follows a normal bit-field, the type of the +zero-length bit-field may affect the alignment of the structure as whole. For +example, @code{t2} has a size of 4 bytes, since the zero-length bit-field follows a +normal bit-field, and is of type short. -@item Even if a zero-length bitfield is not followed by a normal bitfield, it may +@item Even if a zero-length bit-field is not followed by a normal bit-field, it may still affect the alignment of the structure: @smallexample @@ -5102,7 +5102,7 @@ struct Here, @code{t4} takes up 4 bytes. @end enumerate -@item Zero-length bitfields following non-bitfield members are ignored: +@item Zero-length bit-fields following non-bit-field members are ignored: @smallexample struct @@ -5266,7 +5266,7 @@ alignment. See your linker documentatio @item packed This attribute, attached to @code{struct} or @code{union} type -definition, specifies that each member (other than zero-width bitfields) +definition, specifies that each member (other than zero-width bit-fields) of the structure or union is placed to minimize the memory required. When attached to an @code{enum} definition, it indicates that the smallest integral type should be used. @@ -5782,11 +5782,11 @@ If you need to read the volatile object occurred, you must use a separate expression with an intervening sequence point. -As bitfields are not individually addressable, volatile bitfields may -be implicitly read when written to, or when adjacent bitfields are -accessed. Bitfield operations may be optimized such that adjacent -bitfields are only partially accessed, if they straddle a storage unit -boundary. For these reasons it is unwise to use volatile bitfields to +As bit-fields are not individually addressable, volatile bit-fields may +be implicitly read when written to, or when adjacent bit-fields are +accessed. Bit-field operations may be optimized such that adjacent +bit-fields are only partially accessed, if they straddle a storage unit +boundary. For these reasons it is unwise to use volatile bit-fields to access hardware. @node Extended Asm @@ -14485,7 +14485,7 @@ always the C-language name. For compatibility with Microsoft Windows compilers, GCC supports a set of @code{#pragma} directives that change the maximum alignment of -members of structures (other than zero-width bitfields), unions, and +members of structures (other than zero-width bit-fields), unions, and classes subsequently defined. The @var{n} value below always is required to be a small power of two and specifies the new alignment in bytes.