Path: csiph.com!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: "Walter Banks" Newsgroups: comp.compilers Subject: Language standards vs. implementation, was Re: A right alternative to IEEE-754's format Date: Tue, 10 Apr 2018 11:07:44 -0400 (EDT) Organization: Aioe.org NNTP Server Lines: 53 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <18-04-018@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=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="52072"; mail-complaints-to="abuse@iecc.com" Keywords: standards Posted-Date: 10 Apr 2018 11:07:44 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-US Xref: csiph.com comp.compilers:2043 [[ this string is copied from comp.arch because your moderation found it interesting ]] On 2018-04-01 11:52 AM, Tim Rentsch wrote: > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > >> A responsible software maintainer does not change behaviour that >> users make use of. See, e.g., >> . > > Interesting article. Thank you for posting it. > >> Unfortunately, there's an epidemic of irresponsibility among C >> compiler maintainers. > > I can't completely agree with this reaction. In some ways, sure, but > for choices that are allowed because of undefined behavior the > question is not so black-and-white. Some of the responsibility > belongs to the ISO C standard (and the people who produce it). > Unfortunately it's a difficult problem; I know there is interest in > the ISO C group to find a middle ground, somewhere between > unspecified behavior and undefined behavior, but it isn't easy to > find that. For example, consider this reasonable-sounding rule: no > library interface should ever result in undefined behavior, not > counting things like bad pointer inputs (and null pointers should > never be in the set of bad inputs). But what about printf()? In > printf() we have an interface with large parts of the input domain > that give undefined behavior. POSIX takes advantage of this to > define the behavior of positional format specifications, which are > quite useful in some contexts. But, and here is the important part, > formats other than those allowed in the POSIX spec /are still > undefined behavior/. Moreover that freedom is important, to allow > further extensions to be added at some later date. > > I should add that I am mostly on your side. I think what compiler > writers are doing with so-called "aggressive optimization" belongs > more to the problem set than the solution set. But solving the > problem has to include getting changes made to the ISO C standard, so > that compiler writers have no choice if they want their stuff to be > conforming. I know doing that is not an easy task; ultimately though > it seems unavoidable if we are to get things to improve. > 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. w..