Path: ...!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: kegs@provalid.com (Kent Dickey)
Newsgroups: comp.arch
Subject: Re: is Vax addressing sane today
Date: Mon, 7 Oct 2024 18:45:01 -0000 (UTC)
Organization: provalid.com
Lines: 71
Message-ID: <ve1a7d$1qjrq$1@dont-email.me>
References: <vbd6b9$g147$1@dont-email.me> <vcso7k$2s2da$1@dont-email.me> <vctke1$33me0$1@dont-email.me> <S9YIO.47284$xO0f.16227@fx48.iad>
Injection-Date: Mon, 07 Oct 2024 20:45:01 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="c10745cc3120d6259e51e3b53c8f3a62";
	logging-data="1920890"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+u1QP4cFaow/e8Kzw+a9CH"
Cancel-Lock: sha1:8D7WhaCWbGGks1YUPb+9tWF6BCo=
X-Newsreader: trn 4.0-test76 (Apr 2, 2001)
Originator: kegs@provalid.com (Kent Dickey)
Bytes: 3236

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