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

[Richard Henderson <rth@twiddle.net>]

On 03/18/2014 05:33 AM, Peter Maydell wrote:
>  ---- 0x7fe9a5f
>  82  mov_i64 tmp1,rcx
>  83  mov_i64 tmp0,rax
>  84  movi_i64 tmp13,$0x1f
>  85  and_i64 tmp1,tmp1,tmp13
>  86  movi_i64 tmp13,$0x1
>  87  sub_i64 tmp3,tmp1,tmp13
>  88  shl_i64 tmp3,tmp0,tmp3
>  89  shl_i64 tmp0,tmp0,tmp1
>  90  ext32u_i64 rax,tmp0
>  91  movi_i64 tmp13,$0x0
>  92  mov_i64 cc_dst,tmp0
>  93  mov_i64 cc_src,tmp3
>  94  movi_i32 tmp5,$0x24
>  95  movi_i32 tmp6,$0x31
>  96  movi_i32 tmp11,$0x0
>  97  mov_i32 tmp12,tmp1
>  98  movcond_i32 cc_op,tmp12,tmp11,tmp5,tmp6,ne
> 
> 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.

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.

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


r~