Tests t007 and t177 from the C++ struct-layout-1 compat tests fail when using GCC 4.3.3 as ALT compilers when testing trunk. The failure for one, check 932 in test t007, is due to a change from r132614 | ebotcazou | 2008-02-25 09:55:26 +0000 (Mon, 25 Feb 2008) | 4 lines * stor-layout.c (layout_decl): Do not bump the alignment of a bit-field to more than byte alignment if it is packed. Here's a smaller C testcase that shows the change: ------------------------------------------------------------------------ #include <stdio.h> struct S932 { long int a; short int b; struct { __attribute__ ((aligned (2))) int d:32; } __attribute__ ((packed)) c; unsigned short int e; }; struct S932 s932; int main () { void *p1, *p2; p1 = &s932; p2 = &s932.e; printf ("offset of e = %lu\n", (unsigned long ) (p2 - p1)); printf ("size of s932 = %lu\n", (unsigned long) sizeof (s932)); return 0; } ------------------------------------------------------------------------ For 4.3.3 the output is: offset of e = 12 size of s932 = 16 For trunk the output is: offset of e = 10 size of s932 = 12 I see this on powerpc64-unknown-linux-gnu with -m32 and -m64, but it looks as if it would affect all targets. Recently, warning option -Wpacked-bitfield-compat was added in r143718 | nemet | 2009-01-27 18:55:20 -0800 (Tue, 27 Jan 2009) | 7 lines * c.opt (Wpacked-bitfield-compat): Change init value to -1. * c-opts.c (c_common_post_options): If -W*packed-bitfield-compat was not supplied then set warn_packed_bitfield_compat to the default value of 1. * stor-layout.c (place_field): Check warn_packed_bitfield_compat against 1. I'd like to see this message, which is on by default, for the change introduced in r132614. I haven't figured out how to determine if the offset for a field has changed, just the alignment. I'll attach my current patch, where the message should be "Perhaps the alignment of packed bit-field <x> has changed in GCC 4.4", which is not terribly useful. The testsuite changes from that patch will be needed if the message is used for t005 and t177. I'll be out of touch for the next week and will be delighted if someone else fixes this.
Created attachment 17505 [details] partial patch to compiler, good patch to testsuite
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00686.html In fact I think the trunk is more correct at least that is the way I read the sizes and offsets.
Also see the thread starting at http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00994.html .
I didn't call it a bug or a regression, but even a deliberate change can produce incompatibilities between objects compiled with different versions of GCC. That's why it would be good to get a suppressible warning/note about it. I copied Eric because he might know where to issue the message so there aren't tons of false positives.
I agree that we need to document this change. And I agree that the new behavior is more reasonable. Can we add this example to changes.html? It looks different enough than the existing one. Did behavior change if you remove the aligned (2) attribute from d? I'm marking this as a regression to be on the radar.
> Did behavior change if you remove the aligned (2) attribute from d? No, it didn't change without the attribute, it was and still is (10, 12).
> I'd like to see this message, which is on by default, for the change > introduced in r132614. I haven't figured out how to determine if the offset > for a field has changed, just the alignment. I'll attach my current patch, > where the message should be "Perhaps the alignment of packed bit-field <x> > has changed in GCC 4.4", which is not terribly useful. I think that's better (without the "perhaps", the alignment is always changed) than "Offset" because this also can change the padding of the structure: struct s { struct { __attribute__ ((aligned (2))) int d:32; } __attribute__ ((packed)) c; unsigned short int e; }; yields (4, 8) with 4.3.3 and (4, 6) with mainline. This apparently will be so uncommon in C/C++ (packed bit-field with alignment attribute) that I'm not sure sure we need to tune it further.
4.4 branch is being closed, moving to 4.5.4 target.
Obsolete by now.