From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5515 invoked by alias); 27 Jan 2012 21:45:33 -0000 Received: (qmail 5500 invoked by uid 22791); 27 Jan 2012 21:45:32 -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:45:18 +0000 From: "eggert at gnu 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:54: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: eggert at gnu dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Status Resolution 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/msg03208.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023 eggert at gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|DUPLICATE | --- Comment #6 from eggert at gnu dot org 2012-01-27 21:44:23 UTC --- This is not a duplicate of Bug 10360 because that was about __alignof__, but this one is about the C11 standard _Alignof/alignof. GCC can assign whatever meaning it likes to __alignof__ but for _Alignof/alignof it should conform to the standard. I agree with Bruno that the bug should be reopened and for now I'm taking the liberty of doing that until the matter is thought through more carefully. In C11, alignof(T) does not mean "the smallest alignment that will used for T in certain contexts". It means "the alignment requirement for T", period; see C11 section 6.5.3.4 paragraph 3. This alignment requirement applies to "every object of that type"; see section 6.2.8 paragraph 1. Members of structures are objects; see section 6.2.5 paragraph 20; and non-bitfield members have addresses and therefore these addresses must be multiples of their types' alignments. In short, GCC's behavior clearly conflicts with C11 here. Andrew gave good ABI examples, where GCC uses different alignments for T depending on context. There's nothing wrong with GCC doing that. All that's required by the standard is that if objects of type T sometimes have alignment X, and sometimes Y, then alignof(T) must yield the minimum of X and Y. (Otherwise, GCC could simply return, say, 2**20 for alignof(X) regardless of X, on the theory that in *some* contexts the alignment is 2**20. :-) Also, this is not simply a question of the C standard. The GCC manual says says (about __alignof__) that it "reports the smallest alignment that GCC will give the data type". It does not say "the smallest alignment that GCC will give the data type outside of a struct". If the intent is that __alignof__ is supposed to be useful only for some contexts in a C program, and not others, then the intent conflicts with GCC's documentation, and either the behavior or the documentation should be fixed for __alignof__. As a practical matter, what would be the point of having alignof yield a value that's greater than the alignment that GCC actually uses for objects? What kind of programs would actually make use of this behavior? I can certainly think of programs it would *break*, e.g., a conservative garbage collector that uses alignof to test whether a purported pointer is actually valid. On balance, it seems that it'd be better to conform to the standard here, instead of having a nonstandard interpretation of alignof.