From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26248 invoked by alias); 27 Jan 2012 21:02:01 -0000 Received: (qmail 26239 invoked by uid 22791); 27 Jan 2012 21:01:59 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 27 Jan 2012 21:01:46 +0000 From: "bruno at clisp dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/52023] _Alignof (double) yields wrong value on x86 Date: Fri, 27 Jan 2012 21:10:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: bruno at clisp dot org X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: CC Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-01/txt/msg03198.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023 bruno at clisp dot org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bruno at clisp dot org --- Comment #2 from bruno at clisp dot org 2012-01-27 21:01:11 UTC --- I can reproduce the bug with gcc version 4.7-20120121 (snapshot) for x86. Test program: =================================================== #include #include #include #include int main () { typedef struct { char slot1; int64_t slot2; } int64_t_helper; typedef struct { char slot1; double slot2; } double_helper; printf ("%d %d %d\n", alignof (int64_t), offsetof (int64_t_helper, slot2), alignof (int64_t) == offsetof (int64_t_helper, slot2)); printf ("%d %d %d\n", alignof (double), offsetof (double_helper, slot2), alignof (double) == offsetof (double_helper, slot2)); } =================================================== Actual output: 8 4 0 8 4 0 Expected output: 4 4 1 4 4 1 (In reply to comment #1) > I don't think this is a bug, the alignment requirements in a struct can be > different from outside of a struct. You could argue like this for __alignof__ which is a GCC invention. But since ISO C11 and since is included, we have to look what ISO C11 says about it. Citing the latest draft of it (n1570.pdf): 6.5.3.4.(3) "The _Alignof operator yields the alignment requirement of its operand type. The operand is not evaluated and the result is an integer constant. When applied to an array type, the result is the alignment requirement of the element type." 3.2 alignment "requirement that objects of a particular type be located on storage boundaries with addresses that are particular multiples of a byte address" 3.15 object "region of data storage in the execution environment, the contents of which can represent values" As a consequence of these definitions, the alignment of a type inside a struct could be a multiple of _Alignof(type), but the alignment of a type inside a struct cannot be less than _Alignof(type). In other words, if alignof (double) == 8 then every 'double' object in memory must be on an address that is a multiple of 8. Then objects inside the 'double_helper' type must also always be at addresses that are a multiple of 8. Which by the rules for structs means that alignof (double_helper) and offsetof (double_helper, slot2) must both be multiples of 8. More about structs in ISO C11: 6.7.2.1.(6) "a structure is a type consisting of a sequence of members, whose storage is allocated in an ordered sequence" 6.7.2.1.(14) "Each non-bit-field member of a structure or union object is aligned in an implementation-defined manner appropriate to its type." Note the last part of the last sentence: "appropriate to its type". The implementation does not have the freedom to ignore the type's alignment when deciding about offsetof of a member in a struct. Please reopen this bug. (I cannot find how to do this witin the bugzilla GUI.)