On 12 August 2011 10:44, Max Filippov <jcmvb...@gmail.com> wrote: > Hello. > >> + case 13: /*QUOSi*/ >> + tcg_gen_div_i32(cpu_R[RRR_R], cpu_R[RRR_S], cpu_R[RRR_T]); >> + break; > > I'm currently developing test suite for xtensa port and found that > with this implementation of QUOS (signed 32-bit division) guest that > divide 0x80000000 by -1 crashes qemu with 'floating point exception' > on x86_64 host.
Yes. See tcg/README, which says: # Undefined behavior if division by zero or overflow. This is basically because the behaviour varies rather from architecture to architecture so (a) it would be a pain to implement consistent handling in the tcg backends and (b) all the front-ends would probably still need special case handling to give the results the guest arch requires. (What is xtensa's behaviour for div by zero and the overflow case ?) > I guess that this is a known issue, at least target-arm has a special > case to handle this. Is there a better way to handle this issue, or > special-casing is the only option? I wouldn't do what target-arm does: it goes out to a helper function, probably because that code predates the addition of brcond to TCG. PPC and MIPS are probably better candidates to crib from, as they both do the special-case checks inline. -- PMM
