Path: csiph.com!3.us.feeder.erje.net!feeder.erje.net!news.linkpendium.com!news.linkpendium.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: David Brown Newsgroups: comp.compilers Subject: Re: Optimization techniques Date: Wed, 1 May 2019 09:20:23 +0200 Organization: A noiseless patient Spider Lines: 56 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <19-05-002@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-052@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="53721"; mail-complaints-to="abuse@iecc.com" Keywords: standards, arithmetic Posted-Date: 01 May 2019 21:31:32 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:2238 On 01/05/2019 03:24, Gene Wirchenko wrote: > On Sun, 28 Apr 2019 23:49:53 +0200, David Brown > wrote: > > [snip] > >> If you are writing your code in a "C with the extra feature of having >> defined behaviour on signed integer overflow", and only compile it with >> suitable compilers (or compiler flags), then that's okay. But don't >> call it correct C code and blame compilers for your own mistakes or >> unwarranted assumptions. > > I would like to see it as part of the language. I *know* that I > want to have an error be thrown at run-time if an error can be > detected. (It is not an unwarranted assumption.) It is not as if > detecting signed integer overflow is a difficult thing on, for > example, System/370, which also dates from 1970. Detecting signed overflow at run-time can be a significant cost. It ruins expression manipulation, optimisation, and simplification - much more than making signed overflow be two's complement. Even compared to a dumb translation compilation of expressions, it nearly doubles the size of the code on many processors as you have to follow each arithmetic instruction with a "jump if overflow". (Some cpus have "trapping" arithmetic instructions, but certainly not all.) On small processors, this is all a heavy penalty on performance. On big processors, simple instructions are often "free" while the cpu is waiting for memory reads, but these sequences thrash your branch prediction buffers. No, throwing an error on overflows is not hard - but it /is/ costly. It can be a marvellous tool during testing and debugging, and may be worth leaving active in some programs, but it has a price. However, if by "part of the language" you are thinking more of optional or configurable possibilities - perhaps like the standard pragmas for controlling some floating point details, then I like that idea. Standard pragmas letting people choose signed overflow behaviour, from the default of "undefined behaviour" to trapping/signalling, two's complement wrapping, and perhaps saturation, would be nice. > > I am fine with compiler options allowing each of us to have our > respective ways. I am tired of the default being "Overflow happens; > too bad". That is why I refuse to use C. It is too dangerous for my > taste. > Choice is a great thing. I don't use C on PC's - not because it is dangerous as such, but because it takes too much effort to use it safely and well. But I use it on small microcontrollers, where I am willing to put in the effort to make the code correct and efficient. On PC's, I mostly use Python - then I don't have to concern myself about overflows (or many other details that the language handles), and I am willing to pay the efficiency price involved.