>> 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 ?)
div by zero -> exception, has a special case handler already; overflow -> result == 0x80000000, no other side effects. >> 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. I meant generally specialcasing vs hw exceptions/whatever. ARM just have it explicitly coded. For xtensa I'd do it inline too. BTW, I see that target-microblaze has the same issue. -- Thanks. -- Max
