Re: Optimization techniques, C++ numeric representations

Hans Aberg <haberg-news@telia.com>
Tue, 30 Apr 2019 15:01:07 +0200

          From comp.compilers

Related articles
Re: Optimization techniques martin@gkc.org.uk (Martin Ward) (2019-04-25)
Re: Optimization techniques haberg-news@telia.com (Hans Aberg) (2019-04-27)
Re: Optimization techniques, C++ numeric representations david.brown@hesbynett.no (David Brown) (2019-04-29)
Re: Optimization techniques, C++ numeric representations haberg-news@telia.com (Hans Aberg) (2019-04-30)
| List of all articles for this month |

From: Hans Aberg <haberg-news@telia.com>
Newsgroups: comp.compilers
Date: Tue, 30 Apr 2019 15:01:07 +0200
Organization: A noiseless patient Spider
References: <72d208c9-169f-155c-5e73-9ca74f78e390@gkc.org.uk> 19-04-020 19-04-033 19-04-043
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="91460"; mail-complaints-to="abuse@iecc.com"
Keywords: arithmetic, design
Posted-Date: 30 Apr 2019 22:18:20 EDT

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


Post a followup to this message

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