Re: Optimization techniques, C++ numeric representations

On 2019-04-29 17:24, David Brown wrote:
> On 27/04/2019 23:01, Hans Aberg wrote:
>> On 2019-04-25 17:46, Martin Ward wrote:
>>> If signed overflow was given a defined
>>> behaviour (such as the two's complement result), then compilers for
>>> CPUs which do not implement two's complement operations would have to
>>> generate less efficient code (but does anyone still make such a CPU?).
>>
>> All C++ compilers use two's complement, and as of C++20, that is
>> required, cf. [1], "Range of values". It is required for int32_t etc in
>> C++11 [2] and C99 [3].
>>
>> 1. https://en.cppreference.com/w/cpp/language/types
>> 2. https://en.cppreference.com/w/cpp/types/integer
>> 3. https://en.cppreference.com/w/c/types/integer
>> [I realize that if you look very hard, you can still find a few legacy
>> machines that are not pure two's complement and do not have 8-bit byte
>> addressing.  But these days, so what. -John]
>
> Note, however, that this applies only to the representation of the
> types.  C++20 will /not/ require two's complement wrapping on signed
> integer overflow - this will remain undefined behaviour.  (And, as
> always, compilers are free to define it if they want.)


For that, one will have to use the unsigned types. It is required in
Java, though, which does not have the unsigned type. So the question is
why UB is kept in C/C++. There is a list of languages here:
      https://en.wikipedia.org/wiki/Integer_overflow

Return to the comp.compilers page.
Search the comp.compilers archives again.