* [Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ
2007-10-20 1:47 [Bug c/33823] New: bitfields on packed struct aligns by a few bits if the types differ alexandre dot nunes at gmail dot com
@ 2007-10-20 1:49 ` alexandre dot nunes at gmail dot com
2007-10-20 9:47 ` rguenth at gcc dot gnu dot org
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: alexandre dot nunes at gmail dot com @ 2007-10-20 1:49 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from alexandre dot nunes at gmail dot com 2007-10-20 01:49 -------
Created an attachment (id=14374)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14374&action=view)
A complete testcase.
I compiled with gcc -ggdb3 file.c -o file, no optimization flags.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33823
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ
2007-10-20 1:47 [Bug c/33823] New: bitfields on packed struct aligns by a few bits if the types differ alexandre dot nunes at gmail dot com
2007-10-20 1:49 ` [Bug c/33823] " alexandre dot nunes at gmail dot com
@ 2007-10-20 9:47 ` rguenth at gcc dot gnu dot org
2007-10-20 12:20 ` alexandre dot nunes at gmail dot com
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2007-10-20 9:47 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-20 09:47 -------
The standard puts all the burden on the implementation (See 6.7.2.1/10).
The GCC manual in turn says the behavior is specified by the ABI (4.9
Structures, unions, enumerations, and bit-fields), which would be the sysv ABI
which I
don't have handy right now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33823
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ
2007-10-20 1:47 [Bug c/33823] New: bitfields on packed struct aligns by a few bits if the types differ alexandre dot nunes at gmail dot com
2007-10-20 1:49 ` [Bug c/33823] " alexandre dot nunes at gmail dot com
2007-10-20 9:47 ` rguenth at gcc dot gnu dot org
@ 2007-10-20 12:20 ` alexandre dot nunes at gmail dot com
2007-10-20 12:55 ` alexandre dot nunes at gmail dot com
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: alexandre dot nunes at gmail dot com @ 2007-10-20 12:20 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from alexandre dot nunes at gmail dot com 2007-10-20 12:20 -------
(In reply to comment #2)
> The standard puts all the burden on the implementation (See 6.7.2.1/10).
> The GCC manual in turn says the behavior is specified by the ABI (4.9
> Structures, unions, enumerations, and bit-fields), which would be the sysv ABI
> which I
> don't have handy right now.
>
Does the ABI dictates the case of how gcc should *pack* the structures? I've
seem that gcc packs structures in a very similar (if not identical) fashion on
some targets (ix86-linux-gnu, arm-elf, mingw without -mms-bitfields, at least),
are they covered by sysv ABI too? Is it a default on gcc whenever the target
has no particular semantics (as arm-elf, which I suppose does not derive from
the ARM published ABIs at all)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33823
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ
2007-10-20 1:47 [Bug c/33823] New: bitfields on packed struct aligns by a few bits if the types differ alexandre dot nunes at gmail dot com
` (2 preceding siblings ...)
2007-10-20 12:20 ` alexandre dot nunes at gmail dot com
@ 2007-10-20 12:55 ` alexandre dot nunes at gmail dot com
2007-10-20 13:35 ` alexandre dot nunes at gmail dot com
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: alexandre dot nunes at gmail dot com @ 2007-10-20 12:55 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from alexandre dot nunes at gmail dot com 2007-10-20 12:55 -------
(In reply to comment #2)
> The standard puts all the burden on the implementation (See 6.7.2.1/10).
> The GCC manual in turn says the behavior is specified by the ABI (4.9
> Structures, unions, enumerations, and bit-fields), which would be the sysv ABI
> which I
> don't have handy right now.
>
http://www.sco.com/developers/devspecs/abi386-4.pdf
Would that be it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33823
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ
2007-10-20 1:47 [Bug c/33823] New: bitfields on packed struct aligns by a few bits if the types differ alexandre dot nunes at gmail dot com
` (3 preceding siblings ...)
2007-10-20 12:55 ` alexandre dot nunes at gmail dot com
@ 2007-10-20 13:35 ` alexandre dot nunes at gmail dot com
2007-11-02 16:58 ` alexandre dot nunes at gmail dot com
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: alexandre dot nunes at gmail dot com @ 2007-10-20 13:35 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from alexandre dot nunes at gmail dot com 2007-10-20 13:35 -------
(In reply to comment #4)
> (In reply to comment #2)
> > The standard puts all the burden on the implementation (See 6.7.2.1/10).
> > The GCC manual in turn says the behavior is specified by the ABI (4.9
> > Structures, unions, enumerations, and bit-fields), which would be the sysv ABI
> > which I
> > don't have handy right now.
> >
>
> http://www.sco.com/developers/devspecs/abi386-4.pdf
>
> Would that be it?
>
I couldn't find (ok, I didn't try hard enough) the generic abi, but the 386 abi
only tells about the case of bitfields on regular structures, i.e. those
without the packed attribute. I do believe that ABI-conformant structures are
always padded (aligned), and the packed structures are outside of the ABI
scope... I'll try and see if I find the generic sysv abi docs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33823
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ
2007-10-20 1:47 [Bug c/33823] New: bitfields on packed struct aligns by a few bits if the types differ alexandre dot nunes at gmail dot com
` (4 preceding siblings ...)
2007-10-20 13:35 ` alexandre dot nunes at gmail dot com
@ 2007-11-02 16:58 ` alexandre dot nunes at gmail dot com
2008-02-14 21:34 ` rguenth at gcc dot gnu dot org
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: alexandre dot nunes at gmail dot com @ 2007-11-02 16:58 UTC (permalink / raw)
To: gcc-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2144 bytes --]
------- Comment #6 from alexandre dot nunes at gmail dot com 2007-11-02 16:58 -------
>From the gcc internals
(http://gcc.gnu.org/onlinedocs/gccint/Storage-Layout.html):
Target Hook: bool TARGET_MS_BITFIELD_LAYOUT_P (tree record_type)
This target hook returns true if bit-fields in the given record_type are to
be laid out following the rules of Microsoft Visual C/C++, namely: (i) a
bit-field won't share the same storage unit with the previous bit-field if
their underlying types have different sizes, and the bit-field will be aligned
to the highest alignment of the underlying types of itself and of the previous
bit-field; (ii) a zero-sized bit-field will affect the alignment of the whole
enclosing structure, even if it is unnamed; except that (iii) a zero-sized
bit-field will be disregarded unless it follows another bit-field of nonzero
size. If this hook returns true, other macros that control bit-field layout are
ignored.
When a bit-field is inserted into a packed record, the whole size of the
underlying type is used by one or more same-size adjacent bit-fields (that is,
if its long:3, 32 bits is used in the record, and any additional adjacent long
bit-fields are packed into the same chunk of 32 bits. However, if the size
changes, a new field of that size is allocated). In an unpacked record, this is
the same as using alignment, but not equivalent when packing.
If both MS bit-fields and `__attribute__((packed))' are used, the latter
will take precedence. If `__attribute__((packed))' is used on a single field
when MS bit-fields are in use, it will take precedence for that field, but the
alignment of the rest of the structure may affect its placement.
... it seems like that the packed attribute has the power of nulify the
ms_struct attribute, but not the gcc_struct one, regarding a rather non-uniform
behaviour if the underlying ABIs are different. It also means that I could use
ms_struct,packed in a portable way (even on architetures where the ms_struct
isn't even an alternative), but gcc_struct,packed is less portable. Right?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33823
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ
2007-10-20 1:47 [Bug c/33823] New: bitfields on packed struct aligns by a few bits if the types differ alexandre dot nunes at gmail dot com
` (5 preceding siblings ...)
2007-11-02 16:58 ` alexandre dot nunes at gmail dot com
@ 2008-02-14 21:34 ` rguenth at gcc dot gnu dot org
2008-02-14 22:07 ` alexandre dot nunes at gmail dot com
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2008-02-14 21:34 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from rguenth at gcc dot gnu dot org 2008-02-14 21:33 -------
Yes, so for packed structs (which are a GCCism), GCC sets the rule. Better
documentation is certainly appreciated, but - what is the bug here? Did
the behavior change (I think it did for some 3.x releases) recently?
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33823
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ
2007-10-20 1:47 [Bug c/33823] New: bitfields on packed struct aligns by a few bits if the types differ alexandre dot nunes at gmail dot com
` (6 preceding siblings ...)
2008-02-14 21:34 ` rguenth at gcc dot gnu dot org
@ 2008-02-14 22:07 ` alexandre dot nunes at gmail dot com
2008-02-14 23:05 ` rguenth at gcc dot gnu dot org
2008-02-14 23:16 ` alexandre dot nunes at gmail dot com
9 siblings, 0 replies; 11+ messages in thread
From: alexandre dot nunes at gmail dot com @ 2008-02-14 22:07 UTC (permalink / raw)
To: gcc-bugs
------- Comment #8 from alexandre dot nunes at gmail dot com 2008-02-14 22:06 -------
(In reply to comment #7)
> Yes, so for packed structs (which are a GCCism), GCC sets the rule. Better
> documentation is certainly appreciated, but - what is the bug here? Did
> the behavior change (I think it did for some 3.x releases) recently?
>
I'm not sure if it's a bug, call it a clarification request, that may or may
not involve a bug: It's stated somewhere in gcc docs that gcc tries to do
things uniformly, only diverging between targets where there's a compelling
reason to do so. So what I'm asking is:
- Is the attribute((packed)) behaviour consistent between gcc ports regarding
bitfield alignments? If not, why?
- If attribute((packed)) is not consistent between gcc ports, could it be made
so? At least sysv abi (as far as I've read) does not mandate anything about the
bitfields within a word. I've not pointed to any ABI that does, however, that
was the explanation I've got. That's where I said the abi could change (for
several arches). You may say it's not worthy, and I would agree, but here is
where the "bug" would (or would not) lie.
- If not and there's no point changing it, could there be another attribute, or
anything, that would have that effect (uniformity between ABIs)?
I understand perfectly that using structures like that is meant to be
non-portable, but it's quite handy to have something like that without too much
worry about platforms, since altough I develop for several arches, almost all
of them today have a gcc port, and I know there are others with similar issues.
If this revert to be a non-bug and I can still hold a feature request on it, I
would be satisfied.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33823
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ
2007-10-20 1:47 [Bug c/33823] New: bitfields on packed struct aligns by a few bits if the types differ alexandre dot nunes at gmail dot com
` (7 preceding siblings ...)
2008-02-14 22:07 ` alexandre dot nunes at gmail dot com
@ 2008-02-14 23:05 ` rguenth at gcc dot gnu dot org
2008-02-14 23:16 ` alexandre dot nunes at gmail dot com
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2008-02-14 23:05 UTC (permalink / raw)
To: gcc-bugs
------- Comment #9 from rguenth at gcc dot gnu dot org 2008-02-14 23:04 -------
We can't change the current behavior/ABI obviously. But the request for better
documentation is correct.
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
Status|WAITING |NEW
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2008-02-14 23:04:27
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33823
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ
2007-10-20 1:47 [Bug c/33823] New: bitfields on packed struct aligns by a few bits if the types differ alexandre dot nunes at gmail dot com
` (8 preceding siblings ...)
2008-02-14 23:05 ` rguenth at gcc dot gnu dot org
@ 2008-02-14 23:16 ` alexandre dot nunes at gmail dot com
9 siblings, 0 replies; 11+ messages in thread
From: alexandre dot nunes at gmail dot com @ 2008-02-14 23:16 UTC (permalink / raw)
To: gcc-bugs
------- Comment #10 from alexandre dot nunes at gmail dot com 2008-02-14 23:15 -------
(In reply to comment #9)
> We can't change the current behavior/ABI obviously. But the request for better
> documentation is correct.
>
Would it be feasibly to have a non-fatal testcase for this, so that it would be
easy to catch (and document) which (if any) targets deviates from this pattern?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33823
^ permalink raw reply [flat|nested] 11+ messages in thread