[PATCH] expr.c:emit_push_insn

[Mark Mitchell]

>>>>> "Kaveh" == Kaveh R Ghazi <ghazi@caip.rutgers.edu> writes:

    Kaveh> It seems like there's agreement on only defining a
    Kaveh> bit_alignment.  That's fine, but I see two issues.

I'm glad you're willing to do this.  That's great.

    Kaveh> 1.  What heuristic should I use to find where bit_alignment
    Kaveh> should be *used*?  (Preferably a grep expr.)  I tried
    Kaveh> '(unsigned|int).*align' as a first guess and got hundreds
    Kaveh> of hits, many (most?) of which look legitimate.

I would start by looking for uses of TYPE_ALIGN and DECL_ALIGN.  (In
fact, the fields in those structurs should have type bit_alignment, or
at least the values returned by the macros.)  Anything read or written
there should have type bit_alignment.  Gradually work out -- if that
means that a function has a bit_alignment parameter, then the callers
must be passing in values of type bit_alignment, too.  And so forth.

Does that make sense?

    Kaveh> 2.  As you can guess from my regex, there isn't a consensus
    Kaveh> in the code as to whether the type is unsigned or int.

It should be unsigned.  Negative alignment doesn't make sense 
to me. :-)

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com