Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Bart Newsgroups: comp.compilers Subject: Re: Optimization techniques and undefined behavior Date: Thu, 2 May 2019 20:04:52 +0100 Organization: virginmedia.com Lines: 49 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <19-05-014@comp.compilers> References: <72d208c9-169f-155c-5e73-9ca74f78e390@gkc.org.uk> <19-04-021@comp.compilers> <19-04-023@comp.compilers> <19-04-037@comp.compilers> <19-04-039@comp.compilers> <19-04-042@comp.compilers> <19-04-044@comp.compilers> <19-04-047@comp.compilers> <19-05-004@comp.compilers> <19-05-008@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="52735"; mail-complaints-to="abuse@iecc.com" Keywords: optimize, standards, errors Posted-Date: 02 May 2019 18:07:19 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Content-Language: en-GB Xref: csiph.com comp.compilers:2250 On 02/05/2019 15:51, David Brown wrote: > On 01/05/2019 14:53, Bart wrote: >> That's just kicking the can further down the road. >> > > Yes (especially for the use of a larger signed type).  That's fine.  C > let's you easily kick the can a /long/ way down the road.  How often do > you need integers that will overflow a 64-bit type? Most of your post seems to take the premise that 64-bit types have such a wide range that you can forget about overflow problems. But the principle is actually the same: two values A and B represented within N-bit types could overflow when performing arithmetic. It doesn't matter if N is 32 or 64. The subject in UB, and whether the possibility of overflow can just be ignored by a language, a language that deals with low-level machine-sized types. You seem OK with a C compiler assuming that overflow cannot happen so that it can generate slightly faster benchmarks. I prefer a language acknowledging that it could happen, and stipulating exactly what does happen. >> If you have two unknown values A and B, and need to multiply, you won't >> know if the result will overflow. >> > > First off, how often do you actually have unknown values to deal with? > Usually you know something at least. The example here was reading values from a file. So they are external data, and will be unknown. > bytes_per_pixel is not going to be more than, say, 16 - that's for > 32-bit per colour, including alpha channel. It shouldn't be, but you might be reading it from a file. > (And one thing we can be sure of here - having two's complement wrapping > arithmetic certainly will not help.) No; neither is unsigned number wrapping. But having gcc do something weird instead, at odds with nearly every other compiler and language, is even less help.