> Why do you need to change varasm.c at all? The hunks seem to be
> completely separate of the attribute.
Because static constructors have fields in the original order, not the
reversed order. Otherwise code like this is miscompiled:
struct foo a = { 1, 2, 3 };
because the 1, 2, 3 are in the C layout order, but the underlying data
needs to be stored in the reversed order.
> which will severely pessimize bitfield accesses to structs with the
> bitfield-order attribute.
The typical use-case for this feature is memory-mapped hardware, where
pessimum access is preferred anyway.
> so you are supporting this as #pragma. Which ends up tacking
> bit_order to each type. Rather than this, why not operate similar
> to the packed pragma, thus, adjust a global variable in
> stor-layout.c.
Because when I first proposed this feature, I was told to do it this
way.
> I don't see a value in attaching 'native' or 'msb'/'lsb' if it is
> equal to 'native'. You un-necessarily pessimize code generation (is
> different code even desired for a "no-op" bit_order attribute?).
If the attribute corresponds to the native mode, it should be a no-op.
The pessimizing only happens when the fields are actually in reverse
order.
> So no, I don't like this post-process layouting thing. It's a
> layouting mode so it should have effects at bitfield layout time.
The actual reversal happens in stor-layout.c. Everything else is
there to compensate for a possible non-linear layout.
