[Bug middle-end/22275] [3.4/4.0/4.1 Regression] bitfield layout change (regression?)
--- Comment #14 from steven at gcc dot gnu dot org 2005-11-07 17:19 --- As an interesting data point: Intel's ICC 8.0 does what GCC 3.3 and earlier do, but it seems that ICC 9.0 follow GCC 3.4 and later... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug middle-end/22275] [3.4/4.0/4.1 Regression] bitfield layout change (regression?)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug middle-end/22275] [3.4/4.0/4.1 Regression] bitfield layout change (regression?)
--- Comment #11 from janis at gcc dot gnu dot org 2005-11-01 16:42 --- A regression hunt identified the following patch: r65207 | jason | 2003-04-03 18:23:04 + (Thu, 03 Apr 2003) | 17 lines * stor-layout.c (do_type_align): New fn, split out from... (layout_decl): ...here. Do all alignment calculations for FIELD_DECLs here. (update_alignment_for_field): Not here. (start_record_layout, debug_rli): Remove unpadded_align. * tree.h (struct record_layout_info_s): Remove unpadded_align. * c-decl.c (finish_enum): Don't set DECL_SIZE, DECL_ALIGN or DECL_MODE on the CONST_DECLs. (finish_struct): Don't mess with DECL_ALIGN. * cp/class.c (build_vtable): Set DECL_ALIGN here. (get_vtable_decl): Not here. (layout_vtable_decl): Or here. (create_vtable_ptr): Or here. (layout_class_type): Or here. (check_bitfield_decl): Don't mess with field alignment. * ada/misc.c (gnat_adjust_rli): #if 0. -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug middle-end/22275] [3.4/4.0/4.1 Regression] bitfield layout change (regression?)
--- Comment #12 from steven at gcc dot gnu dot org 2005-11-01 16:44 --- The mail to gcc-patches for the patch identified in comment #11 is http://gcc.gnu.org/ml/gcc-patches/2003-04/msg00209.html. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||steven at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug middle-end/22275] [3.4/4.0/4.1 Regression] bitfield layout change (regression?)
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-11-01 16:57 --- Related to PR 10145 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug middle-end/22275] [3.4/4.0/4.1 Regression] bitfield layout change (regression?)
--- Comment #8 from steven at gcc dot gnu dot org 2005-10-31 17:31 --- Right, I didn't know this wasn't opened until July of this year, sorry. I should have looked. I still am not sure whether this does break a documented ABI. Relevant texts in C99 are 6.2.6.1 sub 4, and 6.7.2.1 sub 3. The test case satisfies 6.7.2.1 sub 3, as far as I can tell: The expression that specifies the width of a bit-field shall be an integer constant expression that has nonnegative value that shall not exceed the number of bits in an object of the type that is specified if the colon and expression are omitted. If the value is zero, the declaration shall have no declarator. Then, 6.2.6.1 sub 4 says: Values stored in bit-fields consist of m bits, where m is the size specified for the bit-field. The object representation is the set of m bits the bit-field comprises in the addressable storage unit holding it. In our case, we have m==0. As far as I can tell (but I'm not exactly a C language lawyer ;-) the standard doesn't say anything about signed or unsigned bit-fields. So how should we interpret this... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug middle-end/22275] [3.4/4.0/4.1 Regression] bitfield layout change (regression?)
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-10-31 23:02 ---
Here is a compile time testcase for easier regression hunting:
typedef int BOOL;
typedef unsigned int UINT;
#pragma pack(1)
typedef struct {
BOOL fFullPathTitle:1;
BOOL fSaveLocalView:1;
BOOL fNotShell:1;
BOOL fSimpleDefault:1;
BOOL fDontShowDescBar:1;
BOOL fNewWindowMode:1;
BOOL fShowCompColor:1;
BOOL fDontPrettyNames:1;
BOOL fAdminsCreateCommonGroups:1;
UINT fUnusedFlags:7;
UINT :0;
UINT fMenuEnumFilter;
} CABINETSTATE;
int f[sizeof(CABINETSTATE) == 8? 1 : -1];
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug middle-end/22275] [3.4/4.0/4.1 Regression] bitfield layout change (regression?)
--- Comment #10 from steven at gcc dot gnu dot org 2005-10-31 23:14 --- I have asked Janis to reghunt this one. The bug also affects ppc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug middle-end/22275] [3.4/4.0/4.1 Regression] bitfield layout change (regression?)
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 03:57 --- This is a showstopper; we need to at least understand why this changed and whether or not we should change it back. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug middle-end/22275] [3.4/4.0/4.1 Regression] bitfield layout change (regression?)
--- Comment #6 from steven at gcc dot gnu dot org 2005-10-31 07:21 --- This was not a show stopper for GCC 3.4 and GCC 4.0. Why is it a show stopper now for GCC 4.1? And we can't unconditionally change it back now. We already have GCC 3.4 and 4.0 based compilers in production environments. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||mark at codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug middle-end/22275] [3.4/4.0/4.1 Regression] bitfield layout change (regression?)
--- Comment #7 from mark at codesourcery dot com 2005-10-31 07:44 --- Subject: Re: [3.4/4.0/4.1 Regression] bitfield layout change (regression?) steven at gcc dot gnu dot org wrote: --- Comment #6 from steven at gcc dot gnu dot org 2005-10-31 07:21 --- This was not a show stopper for GCC 3.4 and GCC 4.0. Why is it a show stopper now for GCC 4.1? And we can't unconditionally change it back now. We already have GCC 3.4 and 4.0 based compilers in production environments. I suspect you didn't realize that the PR wasn't opened until July; I had no knowledge of it when 3.4 or 4.0 were released. If I had, I would have declared it a showstopper then. Now, it's a showstopper to figure out what happened and make an informed decision. If we conform to a published ABI where we did not before, maybe we do nothing; this is a bug fix. If we now fail to conform to a published ABI, maybe we add a switch. But, we certainly have to evaluate it before the release. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug middle-end/22275] [3.4/4.0/4.1 Regression] bitfield layout change (regression?)
--- Comment #4 from steven at gcc dot gnu dot org 2005-10-17 15:09 --- If you add a line to the test case: printf (%d\n, offsetof (CABINETSTATE, fMenuEnumFilter)); you get 2 for GCC 4.1, and 4 for GCC 3.3. So this is definitely an ABI change. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-17 15:09:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug middle-end/22275] [3.4/4.0/4.1 Regression] bitfield layout change (regression?)
-- What|Removed |Added Target Milestone|4.0.2 |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug middle-end/22275] [3.4/4.0/4.1 Regression] bitfield layout change (regression?)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-22 21:13 --- Moving to 4.0.2 pre Mark. -- What|Removed |Added Target Milestone|3.4.5 |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug middle-end/22275] [3.4/4.0/4.1 Regression] bitfield layout change (regression?)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02 15:08 --- 3.4.0 also fails on your test so it is not the bit-field changes in 4.0.0 which caused this. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c |middle-end Keywords||ABI Known to fail||3.4.0 4.0.0 4.1.0 Summary|bitfield layout change |[3.4/4.0/4.1 Regression] |(regression?) |bitfield layout change ||(regression?) Target Milestone|--- |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
