Re: integer overflow during divl instruction

[Jose E. Marchesi]

> "Jose E. Marchesi" <jemarch@gnu.org> writes:
>
>>>> Division by -1 is also known to cause signed integer overflow. In this
>>>> case, on x86_64 CPUs, you don't even need a '-ftrapv' option. Test case:
>>>>
>>>> (poke) var x = -4611686018427387904;
>>>> (poke) var y = 2*x;
>>>> (poke) y / -1
>>>> Gleitkomma-Ausnahme (Speicherabzug geschrieben)
>>>>
>>>> In the debugger:
>>>>
>>>> (poke) var x = -4611686018427387904;
>>>> (poke) var y = 2*x;
>>>> (poke) y / -1
>>>>
>>>> Thread 1 "poke" received signal SIGFPE, Arithmetic exception.
>>>> 0x00007ffff7b8ea84 in pvm_execute_or_initialize (jitter_initialize=63,
>>>> jitter_initial_program_point=0xac5f90,
>>>>     jitter_original_state=0x632310) at ../../libpoke/pvm.jitter:2325
>>>> 2325        PVM_CHECKED_BINOP (LONG, LONG, LONG, /);
>>>>
>>>> You should get away without a crash by using the INT_DIVIDE_OVERFLOW
>>>> macro from Gnulib's intprops.h.
>>>
>>> I don't think we can use these macros, which are tailored to C values
>>> and their types.
>>>
>>> In Poke we have integer values of any number of bits from 1 to 63.  If
>>> we were to define what happens when signed overflow occurs (like raising
>>> an exception E_overflow) that would need to happen also when a, say,
>>> 4-bit signed integer is overflown by an operation.
>>>
>>> So we need something more complex than that.
>>
>> For signed division, given a N-bit signed integer, detecting overflow is
>> easy:
>>
>>  a / b
>>
>>   if (a == ((uint64_t) 1 << (N - 1)) (N) && b == -1)
>>     raise E_overflow;
>>
>> According to the discussion in the Hacker's Delight, detecting signed
>> multiplication is not that easy.  Looking into that...
>>
>> Also we need overflow detection for signed addition and subtraction.
>>
>> Also, seems like GCC provides some builtins that may be more efficient
>> to use, conditionally if we are building with GCC.
>
> Years ago I started writing a C++ monstrosity that would handle these
> overflows also using gcc's builtins[1], but I never finished it beyond
> implementing addition overflows. However, you might find [2] quite
> useful, as it contains tested code snippets to detect overflows.

Yeah, it is messy :D

Fortunately the later clever suggestion from Bruno on how to leverage
the gnulib macros allows us to abstract from that complexity.