Richard Sandiford <rdsandif...@googlemail.com> wrote: >Kenneth Zadeck <zad...@naturalbridge.com> writes: >>>>>> #define WIDE_INT_MAX_ELTS \ >>>>>> - ((4 * MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT - 1) \ >>>>>> - / HOST_BITS_PER_WIDE_INT) >>>>>> + (((MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT - 1) \ >>>>>> + / HOST_BITS_PER_WIDE_INT) + 1) >>>>> I think this should be: >>>>> >>>>> (MAX_BITSIZE_MODE_ANY_INT / HOST_BITS_PER_WIDE_INT + 1) >>>>> >>>>> We only need an extra HWI if MAX_BITSIZE_MODE_ANY_INT is an exact >multiple >>>>> of HOST_BITS_PER_WIDE_INT. >>>> we will do this later when some other issues that Eric B raised are >settled. >>> I think you're talking about defining MAX_BITSIZE_MODE_ANY_INT as >>> MAX_SIZE_MODE_ANY_INT * BITS_PER_UNIT, but that's orthogonal to the >>> change above. IMO it doesn't make sense to both round up the >division >>> and also add 1 to the result. So I think we should make this change >>> regardless of whatever follows. >>> >>> Looks good to me otherwise, thanks. >>> >>> Richard >>> >> so this one works the way you want. While it is true the the >problems >> are disjoint, the solution will likely evolving change the same lines >of >> source in two different ways. > >Well, if we're changing the definition of WIDE_INT_MAX_ELTS now (and we >are) >I think we should change it to something that makes sense. All we want >is >1 extra bit. We don't need to round up the size and then add a whole >HWI on top. Doing that will potentially pessimise targets that don't >need anything beyond SImode.
I agree. Richard. >It's not like I can approve the patch anyway though, so I'll leave it >there. > >Thanks, >Richard
