This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: Miscompilation of remainder expressions
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: "'Joe Buck'" <Joe dot Buck at synopsys dot COM>, "'Andrew Haley'" <aph at redhat dot com>
- Cc: "'Ian Lance Taylor'" <iant at google dot com>, "'Gabriel Dos Reis'" <gdr at cs dot tamu dot edu>, "'Roberto Bagnara'" <bagnara at cs dot unipr dot it>, <gcc at gcc dot gnu dot org>
- Date: Wed, 17 Jan 2007 19:13:24 -0000
- Subject: RE: Miscompilation of remainder expressions
On 17 January 2007 19:09, Joe Buck wrote:
> 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.
Didn't someone suggest a no-op prefix somewhere back up-thread?
cheers,
DaveK
--
Can't think of a witty .sigline today....