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: "Tim Rentsch" Newsgroups: comp.compilers Subject: Language standards vs. implementation, was Re: A right alternative to IEEE-754's format Date: 6 Apr 2018 01:01:36 -0700 Organization: A noiseless patient Spider Lines: 42 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <18-04-021@comp.compilers> References: <0d4dc7f8-1819-43e5-8082-6ff7aee5f41b@googlegroups.com> <2018Mar31.160556@mips.complang.tuwien.ac.at> <2018Mar31.195714@mips.complang.tuwien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="52463"; mail-complaints-to="abuse@iecc.com" Keywords: standards Posted-Date: 10 Apr 2018 11:08:27 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:2044 [[ this string is copied from comp.arch because your moderation found it interesting ]] Walter Banks writes: > As someone who has done a significant amount of compiler development > there really never enough testing. Once past sanity tests and > detailed test suites a lot can be gained just by running regression > tests even if the tests are not executed. Detailed metrics alone > can be a very revealing indication of significant compiler problems. > > This can be especially true while developing optimization a > surprising number of new optimizations do not have the intended > effect on old functioning programs. I think what I meant didn't come across the way I meant it. I agree with what (I think) you are saying: it's hard to test compilers effectively, and it is much harder to test heavily optimizing compilers effectively. In fact this raises an interesting question, namely, what is a good methodology for testing compilers in the presence of heavy optimization and programs that may be "broken" in the sense of having undefined behavior. That strikes me as a topic worth pursuing (along with all the other topics on that list, which wasn't short to begin with). However all that is orthogonal to what I was trying to say in my previous comments. My comments are not about verifying how a compiler behaves but about validating the requirements for how the compiler should behave. More specifically, in what cases do we /want/ a compiler to take advantage, or be allowed to take advantage, of the freedom that "undefined behavior" provides? I am convinced that in some cases compilers take greater advantage than is helpful, in the sense of total cost of ownership. Let me emphasize here: not greater advantage than the Standard allows, but greater advantage than is helpful when considering the whole picture. I don't know what is the solution to this problem, but I have no doubt that there is a problem, and one that needs to be addressed at a high level rather than a patchwork quilt of local fixes. Did that make things any clearer? I hope it did.