Re: g++ 3.1 EH broken for irix6.5

[Richard Sandiford <r dot sandiford at redhat dot com>]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

>     The unwinder uses the following union:
> 
>     union unaligned
>     {
>       void *p;
>       unsigned u2 __attribute__ ((mode (HI)));
>       unsigned u4 __attribute__ ((mode (SI)));
>       unsigned u8 __attribute__ ((mode (DI)));
>       signed s2 __attribute__ ((mode (HI)));
>       signed s4 __attribute__ ((mode (SI)));
>       signed s8 __attribute__ ((mode (DI)));
>     } __attribute__ ((packed));
> 
>     The fields with mode attributes get a default alignment that matches
>     their mode (16 for HImode, etc.).  It used to be code in the else-if
>     clause below that set the alignment of mode-annotated fields to the
>     required BITS_PER_UNIT.  But since union fields are set up with a
>     known_align of 0, that code is no longer triggered.
> 
>     I'm confused as to why known_align is being used for packed decls.
>     Doesn't the fact that something is packed mean that nothing is known
>     about its alignment?
> 
> No.  "packed" means "pack this as tightly as possible" meaning to not leave
> any padding between fields.  It also means not to leave any padding at the
> end of the object.  But that leaves totally open what alignment to assign
> to the object, so one might as well assign the most efficient alignment
> consistent with not having any padding, which in this case is the maximum
> alignment.

What about arrays of packed structures?

	struct a { int i; char c; } __attribute__ ((packed));
	struct a as [4];

The alignment of as[0] will be different from as[1].  I don't see
how can you relax the alignment for any field in a packed structure.

> You really don't want to pessimize struct layout so that every packed
> record has only byte-alignment since that's unnecessary.

I don't understand what case your patch was handling.  I assume you had a
case in which a packed field's existing alignment was greater than
BITS_PER_UNIT.

If I understand the code correctly, it's finish_struct() that normally sets
the alignment of a decl to the type's natural alignment.  But it doesn't do
that for packed decls, so in most cases the decl will already have a byte
alignment.

The unwinder's union had fields with "mode" attributes.  That is one case in
which the existing alignment *will* be greater than BITS_PER_UNIT.  The mode
attribute is processed right after the field has been parsed, before it's
known that the structure it belongs to is packed.  So the attribute-handling
code sets the decl to have the mode's natural alignment, and that must
later be corrected by finish_struct()'s call to layout_decl().

Richard