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