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~
