Hi Segher, On Wednesday 05 September 2018 02:51 AM, Segher Boessenkool wrote: > On Mon, Sep 03, 2018 at 08:49:38PM +0530, Sandipan Das wrote: >> +#ifdef __powerpc64__ >> + case 265: /* modud */ >> + if (!cpu_has_feature(CPU_FTR_ARCH_300)) >> + return -1; >> + op->val = regs->gpr[ra] % regs->gpr[rb]; >> + goto compute_done; >> +#endif > > The mod instruction has special cases that aren't handled by this C code, > too (divide by 0, or signed division of the most negative number by -1). > For the mod intruction the behaviour is undefined in those cases, but you > probably should force some specific behaviour. You don't want the kernel > to execute a trap instruction, etc. :-) >
Agreed. In that case, the same would apply to the divw, divwu, divd and divdu instructions as well, right? Cause I don't see these cases being handled for them currently. Also, if I execute a modulo or division instruction for any of these special cases in a userspace binary, I don't see any exceptions being generated. It's just that the result is undefined (usually same as one of the source operands, I don't remember if it was the dividend or the divisor). So, I'm wondering if this would be necessary. - Sandipan
