> Ok, but as we are dealing exclusively with bitfields there is
> already output_constructor_bitfield which uses an intermediate
> state to "pack" bits into units that are then emitted. It shouldn't
> be hard to change that to make it pack into the appropriate bits
> instead.
That assumes that t
On Wed, Jul 2, 2014 at 7:10 AM, DJ Delorie wrote:
>
> Revisiting an old thread, as I still want to get this feature in...
>
> https://gcc.gnu.org/ml/gcc/2012-10/msg00099.html
>
>> >> Why do you need to change varasm.c at all? The hunks seem to be
>> >> completely separate of the attribute.
>> >
>
Revisiting an old thread, as I still want to get this feature in...
https://gcc.gnu.org/ml/gcc/2012-10/msg00099.html
> >> 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 or
On Fri, Oct 5, 2012 at 8:15 PM, DJ Delorie wrote:
>
>
>> 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:
> 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
On Thu, Oct 4, 2012 at 8:38 PM, DJ Delorie wrote:
>
>> ChangeLog missing, new functions need a toplevel comment documenting
>> function, argument and return value as per coding conventions.
>
> Any review of the patch itself? I know the overhead is not there...
Why do you need to change varasm.c
> ChangeLog missing, new functions need a toplevel comment documenting
> function, argument and return value as per coding conventions.
Any review of the patch itself? I know the overhead is not there...
On Wed, Oct 3, 2012 at 12:07 AM, DJ Delorie wrote:
>
> Here's my current patch for the bitfield reversal feature I've been
> working on for a while, with an RX-specific pragma to apply it
> "globally". Could someone please review this? It would be nice
> to get it in before stage1 closes again..
[sorry, should have gone to gcc-patches]
