On Mon, Jan 15, 2007 at 10:34:23PM +0200, Michael Veksler wrote:
> Roberto Bagnara wrote:
> >
> >Reading the thread "Autoconf manual's coverage of signed integer
> >overflow & portability" I was horrified to discover about GCC's
> >miscompilation of the remainder expression that causes INT_MIN % -1
> >to cause a SIGFPE on CPUs of the i386 family. Are there plans to
> >fix this bug (which, to me, looks quite serious)?
> >All the best,
> >
> This problem is quite rare in practice (otherwise there would be
> much more complaining). As such it may be too expensive,
> performance-wise, to fix in GCC. It seems as one of those
> classical things that can be worked-around in the kernel.
>
> Once the kernel sees the FP trap (whatever its i368 name is),
> it decodes the machine code and finds:
> idivl (%ecx).
> As far as I remember, this will put the result in two registers
> one for div_res and one for mod_res.
>
> Since MIN_INT/-1 is undefined, the kernel may put MIN_INT
> in div_res, and mod_res=1. Then return to the following instruction.
>
> Should I open a request for the kernel?
No, because the instruction has actually two result values:
- the remainder, which you could safely set to zero (not 1!)
- the quotient, which is affected by the overflow and there may be
compiler and languages that rely on the exception being generated.
The kernel cannot know whether you are going to use
the quotient or not by simply decoding the instruction.
Actually I believe that a%b and a%(-b) always return the same value
if we follow the C99 specification. So if you are only interested
in the remainder, you can simply use a%abs(b) instead of a%b. The
overhead of abs() is really small.
Gabriel
