Path: csiph.com!xmission!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Hans Aberg Newsgroups: comp.compilers Subject: Re: Optimization techniques, C++ numeric representations Date: Tue, 30 Apr 2019 15:01:07 +0200 Organization: A noiseless patient Spider Lines: 28 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <19-04-048@comp.compilers> References: <72d208c9-169f-155c-5e73-9ca74f78e390@gkc.org.uk> <19-04-020@comp.compilers> <19-04-033@comp.compilers> <19-04-043@comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:2232 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