On Wed, Jan 17, 2007 at 05:48:34PM +0000, Andrew Haley wrote: > From a performance/convenience angle, the best place to handle this is > either libc or the kernel. Either of these can quite easily fix up > the operands when a trap happens, with zero performance degradation of > existing code. I don't think there's any need for gcc to be altered > to handle this.
How will the kernel know whether the overflow in the divide instruction is because the user's source code has a '%' and not a '/'? We generate the exact same instruction for i / minus_one(), after all, and in that case the trap really should be there. I suppose that the trap handler could try to analyze the code following the divide instruction; if the quotient result is never used and the divisor is -1, it could replace the remainder result with zero and return. But that would be rather hairy, if it is even feasible. Alternatively, the divide instruction could be marked somehow, but I have no idea how.
