This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Reorder some tree codes
> Zack Weinberg wrote:
> > Reducing the width of IN_RANGE from unsigned HOST_WIDE_INT to unsigned
> > makes me nervous. Why did you need to do that?
>
>
> That is suspicious. I originally thought the only use was in
> java/lex.c, but now I see that it is used in the back end as
> well. Nathan?
> Mark Mitchell
When I originally added IN_RANGE() a few years ago, it was for curing
some warnings, both "signed/unsigned" and "unsigned >= 0 always true".
The reason it was needed was because some target macros accepting
parameters received a mix of signed, unsigned, HOST_WIDE_INT and
unsigned HOST_WIDE_INT arguments at different points all over the
source base. These arguments were used in comparisons with sign
mismatches or against zero making it impossible to fix at each call
site for all targets.
Using IN_RANGE, and using the widest type was the only safe solution
for a general purpose macro. So I don't think we should narrow it
without considering where it's used.
However using the widest type unnecessarily may involve a
micro-pessimization which could negate Nathan's improvement.
Perhaps a transitional solution would be to add specific width
versions of IN_RANGE for use where we know a narrow type is ok, and
leave IN_RANGE unchanged.
E.g. add IN_RANGE_INT(), IN_RANGE_WIDE(), etc.
Comments included in the definitions should make clear that the _INT
and _WIDE refer to the type of the arguments, not the range between
LOWER and UPPER bounds.
--Kaveh
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu