Re: signed is undefined and has been since 1992 (in GCC)

[Gabriel Paubert <paubert@iram.es>]

On Tue, Jun 28, 2005 at 02:32:04PM +0200, Gabriel Dos Reis wrote:
> Robert Dewar <dewar@adacore.com> writes:
> 
> | Gabriel Dos Reis wrote:
> | 
> | > The issue here is whether if the hardware consistently display a
> | > semantics, GCC should not allow access to that consistent semantics
> | > under the name that "the standard says it is undefined behaviour".
> | > Consider the case of converting a void* to a F*, where F is a function
> | > type.
> | 
> | Well the "hardware consistently displaying a semantics" is not so
> | cut and dried as you think (consider the loop instruction and other
> | arithmetic on the x86 for instance in the context of generating code
> | for loops).
> 
> Please do remember that this is hardware dependent.  If you have
> problems with x86, it does not mean you have the same witha PPC or a
> Sparc. 

For the matter, PPC also has undefined behaviour for integer divides
of 0x80000000 by -1 (according to the architecture specification).
I just checked on a 400MHz PPC750, and the result register ends
up containing -1. 

A side effect is that (INT_MIN % -1) is INT_MAX, which is really 
surprising. I believe that it is reasonable to expect that the 
absolute value of x%y is less than the absolute value of y; it 
might even be required by some language standard.

On x86, the same operation results in a "divide by zero" exception
(vector 0) and a signal under most (all?) operating systems
(SIGFPE under Linux).

Now in practice what would be the cost of checking that the divisor
is -1 and take an alternate path that computes the correct 
results (in modulo arithmetic) for this case ? 

I can see a moderate code size impact, something like 4 or 5 machine
instructions per integer division, not really a performance impact
since on one branch you would have a divide instruction which takes
many clock cycles.

	Regards,
	Gabriel