Re: [Qemu-devel] target-i386: guest variable shift by 0 provokes shift by -1

[Peter Maydell]

On 18 March 2014 14:20, Richard Henderson <address@hidden> wrote:
> On 03/18/2014 05:33 AM, Peter Maydell wrote:
>> In this case the constant propagation code is smart
>> enough to figure out that tmp1 is always zero at op 85,
>> and therefore tmp3 is -1 at op 87. It then tries to use
>> the shift constant of -1 in C when looking at op 88, and
>> clang complains about the C undefined behaviour.
>
> The tcg ops are fine here.

Why do you think this? tcg/README says out of
range shifts are undefined behaviour. That means we
mustn't execute them, and this code doesn't attempt
to branch around or otherwise avoid the shift by -1.

> We've determined that cc_dst and cc_src are not live at the moment, since the
> xor set cc_op to CC_OP_CLR which does not use them.  We optimistically store
> into them, and then conditionally store into cc_op itself at the end.
>
> So the shift is undefined (even by tcg's rules), but the result is unused.

The docs say undefined behaviour, not undefined
result value... (Is there a C standard term for
the latter?)

> So the complaint must be within tcg/optimizer.c?  We can shut up clang by
> masking the shift operand while performing constant folding.

I think the optimizer is legitimately relying on
the frontend producing TCG that isn't breaking the
rules about undefined behaviour.

thanks
-- PMM