On 18 March 2014 14:20, Richard Henderson <r...@twiddle.net> 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
