This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] expr.c:emit_push_insn
- To: ghazi at caip dot rutgers dot edu
- Subject: Re: [PATCH] expr.c:emit_push_insn
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Fri, 11 May 2001 14:04:47 -0700
- Cc: dje at watson dot ibm dot com, rth at redhat dot com, gcc-patches at gcc dot gnu dot org
- Organization: CodeSourcery, LLC
- References: <200105112015.QAA22136@caip.rutgers.edu>
>>>>> "Kaveh" == Kaveh R Ghazi <firstname.lastname@example.org> 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 email@example.com
CodeSourcery, LLC http://www.codesourcery.com