patch to fix

[Marc Glisse]

On Thu, 4 Oct 2012, Kenneth Zadeck wrote:

> There are a bunch of ways to skin the cat.
>
> 1) we can define the extra mode.
> 2) if we get rid of the mode inside the wide int and replace it with an 
> explicit precision and bitsize, then we can just make the size of the buffer 
> twice as big as the analysis of the modes indicates.
> 3) or we can leave your code in a form that uses 2 wide ints.   my current 
> patch (which i have not gotten working yet) changes this to use the mul_full 
> call, but it could be changed.   It is much simpler that the existing code.

Thanks, we are exactly on the same page :-)

> i do not see how templates offer any solution at all.   the wide int code 
> really needs to have something valid to indicate the length of the object, 
> and if there is no mode that big, the code will ice.

It would be possible to define the regular wide_int taking into account 
only valid modes, and only use the dummy larger modes in very specific 
circumstances, where the template parameter would somehow indicate the 
last mode that may appear in it. This is not a recommendation at all, just 
an explanation of why templates might have had something to do with it.

> my personal feeling is that range analysis is quite useful for small integers 
> and not so much as the values get larger.   The only really large integer 
> constants that you are likely to find in real code are encryption keys,

Note that gcc regularly decides to use unsigned types where the code is 
signed, so a "small" constant like -1 can be huge.

-- 
Marc Glisse