Re: is Vax addressing sane today

In article <S9YIO.47284$xO0f.16227@fx48.iad>,
EricP  <ThatWouldBeTelling@thevillage.com> wrote:

Terje Mathisen wrote:

Kent Dickey wrote:

>
Look at:
https://godbolt.org/z/oMhW55YsK
>
Which is this code:
>
int add2(int num, int other) {
     return num + other;
}
>
Compiled with these options:  -O2 -ftrapv
(-ftrapv is the GCC argument for detect signed overflows and crash).
>
For x86-64 clang 19.1.0:
>
add2:
         add     edi, esi
         jo      .LBB0_1
         mov     eax, edi
         ret
.LBB0_1:
         ud1     eax, dword ptr [eax]
>
This looks OK: it does a normal add, then branches-on-overflow to
an undefined instruction.
>
But x86 has an instruction to trap on overflow directly: INTO.  It's
one byte.
And it doesn't use it.
>
GCC x86-64 14.2 is even worse:
>
add2:
         sub     rsp, 8
         call    __addvsi3
         add     rsp, 8
         ret
>
It calls a routine to do all additions which might overflow, and that
routine calls assert() if an overflow occurs.
>
The CPU has a trap-on-overflow instruction exactly for this case (to
crash
on detecting an overflow), and compilers don't even use it.
>
So even on architectures which have a trap-on-overflow instruction,
compilers don't use it.

 
You can only compile in INTO opcodes if you can guarantee that the INT 4
(INTO) trap vector will always be set to a proper handler, and since
that isn't part of the ABI, compilers can't depend on it?
 
I do agree that it would be nice if it did work, barring that clang is
doing the best possible alternative, at close to zero cost except for
the useless branch predictor table entry wastage.
 
Terje

>
On x64 in 64-bit mode INTO is among 21 opcodes reassigned as invalid.
One must use JO to detect signed overflow.
Others were repurposed, 1-byte INC and DEC 40..4F became the REX prefix.

Right, I forgot this.  But even in 32-bit mode compiles, GCC and CLANG
both do not use INTO when using the -ftrapv flag--the compilers do the same
thing they do in 64-bit mode.

Kent