Bug in highest_pow2_factor
Mark Mitchell
mark@codesourcery.com
Thu May 2 12:52:00 GMT 2002
--On Thursday, May 02, 2002 03:01:13 PM -0400 Richard Kenner
<kenner@vlsi1.ultra.nyu.edu> wrote:
> It seems like you're assuming exp is always unsigned. So, why not
> just return "unsigned HOST_WIDE_INT" from the function?
>
> You already cast pow2 to that type in offset_address, so it looks
> like the interface is wrong; these things should be unsigned in the
> first place.
>
> That's a tricky one, but exposes more problems in that function than I
> think we can fix in the 3.1 timeframe.
Well, so far, we don't even have a regression, so I'm not sure we have
to do anything for 3.1. I'm trying to understand this better.
> The point is that the function is intended to return "small" values, where
> "small" isn't too well defined. Returning the unsigned equivalent of the
> most negative number is almost guaranteed to overflow when used later.
So, check for overflow later. Or, define the function to never return a
value bigger than BIGGEST_ALIGNMENT, and then do that in the case you
have by masking out bits if c0 that are bigger than that.
> I think that for the trunk, the function needs to carefully check for
> overflow, which it doesn't now. I could argue both sides of whether its
> return type should be signed or unsigned.
I agree we don't have to fix this, if we adopt the BIGGEST_ALIGNMENT
restriction proposed above, but I don't see why this should be signed.
Is the "highest power of two" ever negative?
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
More information about the Gcc-patches
mailing list