[m-dev.] diff: additions to const_prop.m

[Fergus Henderson]

On 30-Mar-1999, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> 
> compiler/const_prop.m:
> 	Optimize `int:unchecked_left_shift/2', `int:unchecked_right_shift/2'
...
> +evaluate_builtin_tri("int", "unchecked_left_shift",
> +		0, X, Y, Z, Z, int_const(ZVal)) :-
> +	X = _XVar - bound(_XUniq, [functor(int_const(XVal), [])]),
> +	Y = _YVar - bound(_YUniq, [functor(int_const(YVal), [])]),
> +	ZVal is unchecked_left_shift(XVal, YVal).
...
> +evaluate_builtin_tri("int", "unchecked_right_shift",
> +		0, X, Y, Z, Z, int_const(ZVal)) :-
> +	X = _XVar - bound(_XUniq, [functor(int_const(XVal), [])]),
> +	Y = _YVar - bound(_YUniq, [functor(int_const(YVal), [])]),
> +	ZVal is unchecked_right_shift(XVal, YVal).

Hmm, this seems to be shifting undefined behaviour at run-time
into undefined behaviour at compile time, which is not a good thing.
Note that undefined behaviour can include reporting an error
or crashing (note the difference between undefined behaviour
and unspecified result).

I think the same comment applies to your recent change to vn_util.m,
which also does the same optimization.

One way to avoid the problem would be to use the checked versions
`<<' and `>>'.  Another way would be to check that the shift count
is in range and to not perform the optimization if it isn't
(thus leaving the undefined behaviour at runtime).  Or if the
shift count is out of range you could transform the code into something
that reports an error at runtime if that code is reached.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.