Path: csiph.com!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: David Brown Newsgroups: comp.compilers Subject: Re: Optimization techniques and undefined behavior Date: Tue, 7 May 2019 16:16:18 +0200 Organization: A noiseless patient Spider Lines: 72 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <19-05-051@comp.compilers> References: <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-045@comp.compilers> <19-04-049@comp.compilers> <19-05-003@comp.compilers> <19-05-009@comp.compilers> <19-05-013@comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="25862"; mail-complaints-to="abuse@iecc.com" Keywords: C, standards Posted-Date: 07 May 2019 18:45:00 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:2286 On 02/05/2019 19:59, Bart wrote: > On 02/05/2019 16:27, David Brown wrote: >> On 01/05/2019 13:40, Bart wrote: > 'Of interest' was a source-to-source translator that removes unnecessary > macros, typedefs, #ifs and #includes from C source code. > >> But if you want to translate your language to C, you need to translate >> it to C - not to what you think C ought to be. > > Read again - the translation goes the other way. > OK, I got that wrong. When you are translating /from/ C, you can assume any behaviour you like for things that are undefined behaviour. I can't understand how you would see the removal of typedefs, macros, etc., to be an advantage - it would make most C code harder to understand. But if you find your tool useful, great. >   Given that you want your >> own language to have wrapping semantics on integer overflow (hey, it's >> your language - you define it in a crazy way if you want), > > You mean, like most processors, most languages and even most C > compilers? Then yeah it's crazy. > Yes, crazy for a language. I think it is hard to define "most languages", but a great many either throw a run-time error or use expanded range numbers - both of which are appropriate (though there is a cost). Several, not just C, assume that overflow doesn't happen as it is undefined behaviour. There are some languages that define it as two's complement wrapping, and that's crazy. I've explained before why /processors/ use two's complement wrapping - it is not because it gives a useful answer. >> What does not make sense, of course, is to run tests in C with undefined >> behaviour and expect consistent or testable results.  That is just daft. > > That was sort of the point of my post - it's daft is for C to declare > such code undefined behaviour, when the general consensus (see above) is > that it can be perfectly well defined. > Proof by repeated assertion is not valid. > >>> The results match those of the non-gcc/non-clang C compilers (apart from >>> speed which is poor).) >> >> Who cares?  The C code is buggy, so the results don't matter. > > The C is only buggy because C says so. The C standards define the c language - if they say the C code is buggy, the C code is buggy. I can't believe you need this explained. > My version is exactly the same > program, and is not buggy because this language doesn't make unsigned > overflow undefined behaviour. (I assume you meant "signed" here.) You are welcome to have an extended C language that defines the behaviour of signed overflow - and the code is not buggy in that language. Some C compilers specifically give that guarantee too (such as gcc with "-fwrapv"), and the code is not buggy for them. For other C compilers that mostly do two's complement wrapping but don't document it, and might behave differently when optimising some types of code, it's a game of chance - that means the code is buggy.