[Bug c/33823] New: bitfields on packed struct aligns by a few bits if the types differ

[Bug c/33823] New: bitfields on packed struct aligns by a few bits if the types differ

[alexandre dot nunes at gmail dot com]

I have two structs (the unions are there for the sake of testing, it still
behaves the same without them):

#define ATTRIBUTE_PACKED_STRUCT __attribute__((gcc_struct,packed))
#include <stdio.h>
#include <stdint.h>

typedef union  ATTRIBUTE_PACKED_STRUCT
{
  struct ATTRIBUTE_PACKED_STRUCT {
    uint8_t a:1,
            b:7,
            c:7;
    uint16_t d:16;
    uint8_t e:7;
    uint8_t f:7;
    uint16_t g:10;
    uint16_t h:10;
    uint16_t i:12;
    uint8_t  j:7;
    uint8_t k:8;
    uint16_t l:15;
  };
  unsigned char values[14];
} test_struct;

typedef union  ATTRIBUTE_PACKED_STRUCT
{
  struct ATTRIBUTE_PACKED_STRUCT {
    uint32_t a:1,
            b:7,
            c:7;
    uint32_t d:16;
    uint32_t e:7;
    uint32_t f:7;
    uint32_t g:10;
    uint32_t h:10;
    uint32_t i:12;
    uint32_t  j:7;
    uint32_t k:8;
    uint32_t l:15;
  };
  unsigned char values[14];
} test_struct2;

These structs have the same effective size, i.e., removing them from the
unions, and having sizeof() applied to them yelds the 14 bytes size, but the
members dispostion differs, i.e. the 'e' member is a bit ahead in the first
struct (test_struct) than in the second. 

I didn't expect the type change to force an alignment. It that's standard
behaviour, then I would like to propose a documentation request; The ms_struct
alignment is described quite well on gcc's page, but gcc's default one isn't.

If that's not expected behaviour, then what would be? In case it is, could
someone please point me to a documentation source, i.e. an ISO C pointer or
whatever reasoning is behind this, if any?

Thanks.


-- 
           Summary: bitfields on packed struct aligns by a few bits if the
                    types differ
           Product: gcc
           Version: 4.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: alexandre dot nunes at gmail dot com
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33823

[Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ

[alexandre dot nunes at gmail dot com]

------- 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

[Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ

[rguenth at gcc dot gnu dot org]

------- 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

[Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ

[alexandre dot nunes at gmail dot com]

------- 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

[Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ

[alexandre dot nunes at gmail dot com]

------- 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

[Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ

[alexandre dot nunes at gmail dot com]

------- 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

[Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ

[alexandre dot nunes at gmail dot com]

[-- 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

[Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ

[rguenth at gcc dot gnu dot org]

------- 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

[Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ

[alexandre dot nunes at gmail dot com]

------- 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

[Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ

[rguenth at gcc dot gnu dot org]

------- 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

[Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ

[alexandre dot nunes at gmail dot com]

------- 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