This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [PATCH] expr.c:emit_push_insn

>>>>> "Kaveh" == Kaveh R Ghazi <> 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. :-)


Mark Mitchell         
CodeSourcery, LLC     

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]