From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; NetCaptor 6.5.0PB8) Description of problem: There is something wrong with gcc's __alignof__ builtin operator. For "double" type it returns 8. But looking at the class layout we see that double is aligned to 4. The situation becomes more strange is we check alignment for "long double" type - it's 4! Following testcase shows the problem with __alignof__ (double)... ----- testcase (fail.cpp) --------------------------------------------- #include <stdio.h> class A { public: int i; double d; } a; int main(){ printf("alignof(double) = %d\n", __alignof__(double)); printf("alignof(A::d) = %d\n", __alignof__(a.d)); printf("offsetof(A, d) = %d\n", (char *)&a.d - (char *) &a); return 0; } ----- testcase output -------------------------------------------------- alignof(double) = 8 alignof(A::d) = 8 offsetof(A, d) = 4 So, what is going on here? If we really have double aligned to 8 bytes, we should get offset 8 within the class. If we have offset 4 bytes, does it mean that alignment is not greater then 4? Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. compile testcase g++3 -c fail.cpp 2. Run to see the output Actual Results: alignof(double) = 8 alignof(A::d) = 8 offsetof(A, d) = 4 Expected Results: number should be equal for all cases Additional info:
This is because of IA-32 ABI which requires aggregate fields bigger than 4 bytes to be only 4 bytes aligned (unless you use -malign-double, which of course breaks the ABI). __alignof__ (double) == 8 is correct, likewise offsetof. __alignof__ (A::d) should probably change, but that's certainly a 3.2 material.
__alignof__ has always been documented as the *recommended* alignment for the type. I don't see that this is a bug at all.