On Wed, Jul 2, 2014 at 7:10 AM, DJ Delorie d...@redhat.com 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.
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 the
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 order, not
On Fri, Oct 5, 2012 at 8:15 PM, DJ Delorie d...@redhat.com 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
On Thu, Oct 4, 2012 at 8:38 PM, DJ Delorie d...@redhat.com 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
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 Wed, Oct 3, 2012 at 12:07 AM, DJ Delorie d...@redhat.com 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
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...
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...
Index: gcc/doc/extend.texi
[sorry, should have gone to gcc-patches]
10 matches
Mail list logo
