Bug with __alignof(double) with Intel C++ compiler on Linux 10.0.023

[brianblank]

When using the Intel C++ compiler, I found that built-in macro __alignof(double) returns 8, but the double alignment appears to be 4. I create a test program below to prove that the "icpc" compiler is returning an alignment of 4.

Program Code:
--------------------------------------
#include

int main() {
struct X {
double a;
char b;
double c;
char d;
double e;
} x;

printf("&a=%x &b=%x &c=%x &d=%x &e=%x ", &x.a, &x.b, &x.c, &x.d, &x.e);
printf("sizeof(double)=%d sizeof(char)=%d __alignof(double)=%d __alignof(char)=%d ",
sizeof(double), sizeof(char), __alignof(double), __alignof(char));

return 1;
}
-------------------------------

Output:
-------------------------------
&a=bfdf39ec
&b=bfdf39f4
&c=bfdf39f8
&d=bfdf3a00
&e=bfdf3a04
sizeof(double)=8
sizeof(char)=1
__alignof(double)=8
__alignof(char)=1
------------------------------

Both &a and &e when performing "mod 8" return 4, but &c mod 8 returns 0. Therefore, this appears to be placing doubles on a 4 byte boundry, not an 8 byte boundry as suggested by __alignof(double).


I'm not sure if the compiler is suppose to be placing doubles on an 8 byte boundry to get better performance, or if __alignof(double) should be returning 4, but either way it looks like there is a bug here.

Thanks,
Brian

[Dale_S_Intel]

Well, sure enough, I'm seeing the same thing. It could be some sort of gcc-compatibility thing, because I get similar results with gcc, but I don't have a definitive answer at this point. At least if you use a specific variable instead of a type it seems to get a more conservative answer, i.e. if you say __alignof(x.a) you get '4'.

If I find out more about the apparent inconsistency, I'll post it here.

Dale