Bug 10360 - __alignof__(double) answer 8
Summary: __alignof__(double) answer 8
Status: REOPENED
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 3.2
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 54188 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-04-09 09:06 UTC by thoran
Modified: 2021-09-25 01:20 UTC (History)
8 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description thoran 2003-04-09 09:06:00 UTC
__alignof__(double) answer 8.  But actually, it is 4 (that's what gcc generates for record).

Apparently the problem happened in gcc 3.0

Release:
gcc 3.2.3

Environment:
Reading specs from /usr/lib/gcc-lib/i386-linux/3.2.3/specs
Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,proto,pascal,objc,ada --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.2 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-java-gc=boehm --enable-objc-gc i386-linux
Thread model: posix
gcc version 3.2.3 20030309 (Debian prerelease)

Linux thc 2.4.20-k7 #1 Tue Jan 14 00:29:06 EST 2003 i686 unknown unknown GNU/Linux

How-To-Repeat:
#include <stdio.h>

struct bla
{
  char c;
  double v;
};

void main (void)
{
  struct bla b;
  printf("align double %d\neffective alignement %d\n", __alignof__(double),
	 ((char *)(&b.v)) - ((char *)(&b.c)));
}
Comment 1 Richard Henderson 2003-04-09 15:40:39 UTC
From: Richard Henderson <rth@redhat.com>
To: Frederic De Jaeger <dejaeger@free.fr>
Cc: rth@gcc.gnu.org, discuss-gnustep@gnu.org, gcc-bugs@gcc.gnu.org,
   gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, richard@brainstorm.co.uk,
   thoran@free.fr, gcc-gnats@gcc.gnu.org
Subject: Re: c/10360: __alignof__(double) answer 8
Date: Wed, 9 Apr 2003 15:40:39 -0700

 On Wed, Apr 09, 2003 at 11:59:58PM +0200, Frederic De Jaeger wrote:
 > Thus, why gcc does not align fields with respect to this *preferred*
 > alignment?
 
 Because the ABI says not to.
 
 > How can I compute the address of a field in a record?
 
 offsetof.
 
 > I need to do this uniformly on all the types.  That means I cannot use
 > the trick : 
 >  offset = (char *)&foo.bla - (char *)&foo.
 > or the "offsetof" macro.
 
 Tough luck then.
 
 > ... and we expect it to return the alignment used by the compiler (and not
 > the *preferred* alignment).
 
 A meaningless number.  Because "the alignment used by the compiler"
 is going to depend on the context in which it is used.
 
 
 r~

Comment 2 Richard Henderson 2003-04-09 17:29:53 UTC
State-Changed-From-To: open->closed
State-Changed-Why: Not a bug.  __alignof__ returns the *preferred* alignment.
    You're seeing other SVr4 ABI rules concerning structures.
Comment 3 dejaeger 2003-04-09 23:59:58 UTC
From: Frederic De Jaeger <dejaeger@free.fr>
To: rth@gcc.gnu.org, discuss-gnustep@gnu.org, gcc-bugs@gcc.gnu.org,
   gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, richard@brainstorm.co.uk,
   thoran@free.fr, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: c/10360: __alignof__(double) answer 8
Date: 09 Apr 2003 23:59:58 +0200

 rth> Synopsis: __alignof__(double) answer 8
 rth> State-Changed-From-To: open->closed
 rth> State-Changed-By: rth
 rth> State-Changed-When: Wed Apr  9 17:29:53 2003
 rth> State-Changed-Why:
 rth>     Not a bug.  __alignof__ returns the *preferred* alignment.
 rth>     You're seeing other SVr4 ABI rules concerning structures.
 
 Thus, why gcc does not align fields with respect to this *preferred*
 alignment?
 How can I compute the address of a field in a record?
 
 I need to do this uniformly on all the types.  That means I cannot use
 the trick : 
  offset = (char *)&foo.bla - (char *)&foo.
 or the "offsetof" macro.
 because I don't know, statically, the type of the record from which I
 need to compute offsets.  
 
 The type information comes from the @encode directive of
 objective-C (ie:  it's a characters string that describe a type).
 Actually, we are using "objc_alignof_type" (from the objective-c API)
 and we expect it to return the alignment used by the compiler (and not
 the *preferred* alignment).
 
 Thanks for your help,
 
 
        Frederic De Jaeger

Comment 4 Richard Henderson 2003-04-10 01:00:00 UTC
From: Richard Henderson <rth@redhat.com>
To: Richard Frith-Macdonald <richard@brainstorm.co.uk>
Cc: gcc-gnats@gcc.gnu.org, thoran@free.fr, nobody@gcc.gnu.org,
   gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org, discuss-gnustep@gnu.org,
   rth@gcc.gnu.org, Frederic De Jaeger <dejaeger@free.fr>
Subject: Re: c/10360: __alignof__(double) answer 8
Date: Thu, 10 Apr 2003 01:00:00 -0700

 On Thu, Apr 10, 2003 at 06:06:44AM +0100, Richard Frith-Macdonald wrote:
 > It would be interesting to know in what sense the alignment is 
 > 'preferred'.
 
 In that it takes one less cycle to load that way?  In that that's
 how data gets aligned which isn't constrained by the ABI?
 
 > Shouldn't this either be fixed as Frederic suggests, or the documentation
 > be changed so that instead of saying 'preferred' it says 'misleading and
 > largely useless'
 
 And indeed, that's what we ALREADY say, except you didn't read it.
 To wit:
 
 	Some machines never actually require alignment; they allow
 	reference to any data type even at an odd addresses. For
 	these machines, __alignof__ reports the recommended alignment
 	of a type.
 
 
 r~
Comment 5 richard 2003-04-10 06:06:44 UTC
From: Richard Frith-Macdonald <richard@brainstorm.co.uk>
To: Richard Henderson <rth@redhat.com>
Cc: gcc-gnats@gcc.gnu.org, thoran@free.fr, nobody@gcc.gnu.org,
   gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org, discuss-gnustep@gnu.org,
   rth@gcc.gnu.org, Frederic De Jaeger <dejaeger@free.fr>
Subject: Re: c/10360: __alignof__(double) answer 8
Date: Thu, 10 Apr 2003 06:06:44 +0100

 On Wednesday, April 9, 2003, at 11:40  pm, Richard Henderson wrote:
 
 > On Wed, Apr 09, 2003 at 11:59:58PM +0200, Frederic De Jaeger wrote:
 >> Thus, why gcc does not align fields with respect to this *preferred*
 >> alignment?
 >
 > Because the ABI says not to.
 
 It would be interesting to know in what sense the alignment is 
 'preferred'.
 Surely if the 'ABI says not to' then the alignment is not preferred?
 
 >> ... and we expect it to return the alignment used by the compiler 
 >> (and not
 >> the *preferred* alignment).
 >
 > A meaningless number.  Because "the alignment used by the compiler"
 > is going to depend on the context in which it is used.
 
 I think that Frederic means the alignment the compiler uses to lay out
 structures in memory.
 
 It's hard to see how that can be context sensistive since the compiler
 needs to know it to access the structure elements via a pointer, so
 the code that stored the structure in memory and the code that
 retrieves it through the pointer have to use the same alignments.
 
 I imagine this is *by far* the most common context in which anyone
 would want to know a type alignment (actually it's the only one I can
 think of off hand).
 
 So if __alignof__ is not returning the alignment of a type for structure
 layout, how can it be returning the 'preferred' alignment.  Shouldn't 
 this
 either be fixed as Frederic suggests, or the documentation be changed
 so that instead of saying 'preferred' it says 'misleading and largely
 useless'
 
 Sorry if this sounds overly aggressive, but I do think that compiler 
 extensions
 should be useful and behave as expected, and this behavior seems to
 mean that __alignof__ fails in this.
 

Comment 6 Andrew Pinski 2012-01-27 21:05:01 UTC
This was closed as invalid so change it to invalid instead of fixed.
Comment 7 Andrew Pinski 2012-01-27 21:06:39 UTC
*** Bug 52023 has been marked as a duplicate of this bug. ***
Comment 8 Andrew Pinski 2012-01-27 21:49:59 UTC
*** Bug 52023 has been marked as a duplicate of this bug. ***
Comment 9 Richard Biener 2012-08-06 10:42:39 UTC
*** Bug 54188 has been marked as a duplicate of this bug. ***
Comment 10 Andrew Pinski 2016-01-30 00:06:14 UTC
*** Bug 69560 has been marked as a duplicate of this bug. ***
Comment 11 Jason Merrill 2018-04-11 02:19:48 UTC
The quoted passage in the documentation now reads

---
Some machines never actually require alignment; they allow reference to any
data type even at an odd address.  For these machines, @code{__alignof__}
reports the smallest alignment that GCC gives the data type, usually as
mandated by the target ABI.
---

which seems clearer that the correct answer here is 4, as specified by the i386 psABI.
Comment 12 joseph@codesourcery.com 2018-04-19 20:14:59 UTC
On Wed, 11 Apr 2018, jason at gcc dot gnu.org wrote:

> The quoted passage in the documentation now reads
> 
> ---
> Some machines never actually require alignment; they allow reference to any
> data type even at an odd address.  For these machines, @code{__alignof__}
> reports the smallest alignment that GCC gives the data type, usually as
> mandated by the target ABI.

That change (r133271) seems incorrect in this context, as it should be the 
alignment given for complete objects.