--- Comment #43 from rguenth at gcc dot gnu dot org 2006-01-27 23:25
---
Can we have an update on this or post the patch to get review please?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
--- Comment #42 from matz at suse dot de 2006-01-23 11:28 ---
Created an attachment (id=10711)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10711&action=view)
Testprogram
This program generates the following output for 3.3-hammer-branch on x86-64:
S_normal_i size 8 alig
--- Comment #41 from matz at suse dot de 2006-01-23 11:23 ---
Created an attachment (id=10710)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10710&action=view)
candidate patch
This patch contains some commented out test code I had in for playing around.
--
http://gcc.gnu.org/
--- Comment #40 from matz at suse dot de 2006-01-23 11:21 ---
Mark, re your comment #38: (my comment #39 actually came before, but I forgot
to press "Commit" :-/ ) the #pragma pack(1) does not influence DECL_PACKED.
It is only set by attribute(packed). That's why the difference of beha
--- Comment #39 from matz at suse dot de 2006-01-23 10:32 ---
Gnah! It's even worse. I spoke too soon, and actually pre-3.4 (3.3 in fact)
has the behaviour _swapped_. I.e. using the example struct I have these
sizes (on i686):
3.3:normal 16, pragma 16, packed 12
4.1+patch: no
--- Comment #38 from mark at codesourcery dot com 2006-01-20 18:02 ---
Subject: Re: [3.4/4.0/4.1/4.2 Regression] bitfield
layout change (regression?)
matz at suse dot de wrote:
> --- Comment #37 from matz at suse dot de 2006-01-20 16:36 ---
> Hmpf. One more difficulty. x86
--- Comment #37 from matz at suse dot de 2006-01-20 16:36 ---
Hmpf. One more difficulty. x86 uses the ADJUST_FIELD_ALIGN macro
to further fiddle with alignments of fields. On x86 this is used to
adjust the alignment of long long to 4 (instead of the natural 8).
This is used only when
--- Comment #36 from matz at suse dot de 2006-01-20 14:01 ---
Yes. Should be done shortly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
--- Comment #35 from mark at codesourcery dot com 2006-01-19 19:14 ---
Subject: Re: [3.4/4.0/4.1/4.2 Regression] bitfield
layout change (regression?)
steven at gcc dot gnu dot org wrote:
> - Older HP compilers and MS compilers use zero-length bit-fields to force
> the following mem
--- Comment #34 from steven at gcc dot gnu dot org 2006-01-19 17:40 ---
I looked up a few links to see how people use zero-length bit-fields and what
semantics they're expecting. I mostly found links to compiler documentation
about how other compilers interpret these bit-fields. Perhaps
--- Comment #33 from mark at codesourcery dot com 2006-01-19 16:59 ---
Subject: Re: [3.4/4.0/4.1/4.2 Regression] bitfield
layout change (regression?)
matz at suse dot de wrote:
> --- Comment #32 from matz at suse dot de 2006-01-19 14:44 ---
> Mark, I agree that it's saner whe
--- Comment #32 from matz at suse dot de 2006-01-19 14:44 ---
Mark, I agree that it's saner when both structures (with #pragma pack and
attribute packed) have the same length of 8 on i686 and x86_64 (because
the bitfield was declared 'int' in difference to 'long' for instance).
Then I h
--- Comment #31 from mark at codesourcery dot com 2006-01-18 23:28 ---
Subject: Re: [3.4/4.0/4.1/4.2 Regression] bitfield
layout change (regression?)
steven at gcc dot gnu dot org wrote:
> --- Comment #30 from steven at gcc dot gnu dot org 2006-01-18 23:08
> ---
> We should
--- Comment #30 from steven at gcc dot gnu dot org 2006-01-18 23:08 ---
We should at least avoid introducing a third variant of how we lay out these
nasty zero-sized friends. People actually use them. For example Wine uses
them to enforce compatible alignment and data layout with MS Wi
--- Comment #29 from mark at codesourcery dot com 2006-01-18 23:00 ---
Subject: Re: [3.4/4.0/4.1/4.2 Regression] bitfield
layout change (regression?)
I think that we should do as follows.
Preserve the original value of maximum_field_alignment when doing
#pragma pack. Then, for zero-
--- Comment #28 from matz at suse dot de 2006-01-17 22:31 ---
And indeed with this testcase:
typedef int BOOL;
typedef unsigned int UINT;
typedef struct {
BOOL fFullPathTitle:1;
BOOL fSaveLocalView:1;
BOOL fNotShell:1;
BOO
--- Comment #27 from matz at suse dot de 2006-01-17 22:12 ---
Funnily I've also looked at stor-layout.c a bit, and basically came to
a similar conclusion and patch like Steven. I agree that as per documentation
PCC_BITFIELD_TYPE_MATTERS overrides EMPTY_FIELD_BOUNDARY. But that was
also
--- Comment #26 from hubicka at gcc dot gnu dot org 2006-01-17 21:07
---
Hi,
I've looked into it for some time, so here is my POV of this ugly issue.
It seems to me that from documentation of EMPTY_FIELD_BOUNDARY in gccint it is
clear that it
should be ignored when PPC_BITFIELD_TYPE_MAT
--- Comment #25 from steven at gcc dot gnu dot org 2006-01-16 23:33 ---
Re. comment #23, iiuc the old behavior was to align the zero-length bitfield,
not the next field. My patch (one of them anyway) switches the order of
EMPTY_FIELD_BOUNDARY and PCC_BITFIELD_TYPE_MATTERS back to how it
--- Comment #24 from steven at gcc dot gnu dot org 2006-01-16 23:31 ---
Realistically, I don't think it's safe to still fix this for GCC 4.1. The
whole thing looks so complicated (to me at least) that the risk of introducing
new bugs just before the release is significant.
It is unfort
--- Comment #23 from matz at suse dot de 2006-01-16 15:14 ---
The x86-64 ABI itself doesn't talk about zero-sized bitfields. So both
behaviours are correct regarding the ABI. It talks about unnamed bitfields
(which zero-sized ones must be) not influencing the overall alignment
of struc
--- Comment #22 from rguenth at gcc dot gnu dot org 2006-01-16 10:22
---
Honza or Micha - can you take over from here?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
--- Comment #21 from steven at gcc dot gnu dot org 2006-01-14 15:55 ---
Created an attachment (id=10641)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10641&action=view)
Fix x86_field_alignment for AMD64 zero-length bitfields; try to revert to
pre-jason ABI
So I'll just admit I ha
--- Comment #20 from steven at gcc dot gnu dot org 2006-01-14 15:35 ---
Indeed, in GCC 3.2 ("GNU C version 3.2.3 (x86_64-unknown-linux-gnu)") initially
we have a DECL_ALIGN of 64 bits for the zero-length bitfield when we enter
field_decl:
Breakpoint 2, place_field (rli=0xa15b30, field=0
--- Comment #19 from steven at gcc dot gnu dot org 2006-01-14 15:17 ---
On AMD64, EMPTY_FIELD_BOUNDARY is 64 bits, so if we honnor that for the
zero-length bitfield, we get a size of 12 for the struct in the test case in
comment #9 (where we apparently expect 8, which is what you get wit
--- Comment #18 from steven at gcc dot gnu dot org 2006-01-14 14:48 ---
This code in layout_decl looks suspicous:
/* Should this be controlled by DECL_USER_ALIGN, too? */
if (maximum_field_alignment != 0)
DECL_ALIGN (decl) = MIN (DECL_ALIGN (decl), maximum_field_ali
--- Comment #17 from steven at gcc dot gnu dot org 2006-01-14 13:57 ---
If the approach is good, we should at least be checking (DECL_BIT_FIELD
(field)) also before forcing things...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
--- Comment #16 from steven at gcc dot gnu dot org 2006-01-14 13:56 ---
With this patch we force the alignment, but I have to admit I have no idea if
this approach is correct. The only other place in stor-layout.c where we look
at EMPTY_FIELD_BOUNDARY is in layout_decl, but that code is
--- Comment #15 from mmitchel at gcc dot gnu dot org 2005-12-20 02:34
---
In this message:
http://gcc.gnu.org/ml/gcc/2005-12/msg00558.html
I suggested that we switch GCC 4.1 back to the pre-3.4 behavior and asked if
there were objections.
--
http://gcc.gnu.org/bugzilla/show_bug.c
29 matches
Mail list logo
