From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Tests in a software release Date: Fri, 17 Nov 2017 19:07:38 -0600 Organization: JSA Research & Innovation Message-ID: References: <12f75e44-f61b-4b59-ab82-3ae9b151f0be@googlegroups.com> Injection-Date: Sat, 18 Nov 2017 01:07:38 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="15790"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: feeder.eternal-september.org comp.lang.ada:48973 Date: 2017-11-17T19:07:38-06:00 List-Id: "Shark8" wrote in message news:12f75e44-f61b-4b59-ab82-3ae9b151f0be@googlegroups.com... > On Thursday, November 16, 2017 at 2:44:12 PM UTC-7, G.B. wrote: >> >> On the contrary: you write the contract's clauses of >> all parties to your compiler and then, once you >> know your code meets the requirements of the contracts, >> you drop checking code accordingly ("optimize") and in >> good conscience. >> >> if X /= X or else X /= X then >> >> -- what, at compile time, >> -- for which which kind of X? > > IEEE754's NaN would yield true in that case, so you can't simply > optimize that away, you'd have to do some analysis of the "="/"/=" > operator. (1) This is not an optimization, it is a Code Quality Warning. Code like the above is either impossibly tricky or is some sort of mistake. But the compiler doesn't change any code to something else in these cases, it expects the programmer to fix their bug. There's no way that the compiler can guess (in general) what mistake the programmer made. The classic example for this sort of case mentioned in the blog is: for I in Arr'range loop for J in Arr'range loop if Arr(I) = Arr(I) then -- !! ... Here, one gets a Code Quality Warning as the condition is always True. It's pretty obvious that the second (I) in the condition is supposed to be a (J), but that's obvious to a human, not to a compiler. (2) But we could make that optimization if we wanted to, a NAN is invalid. And operations on an invalid value are implementation-defined (if Constraint_Erorr or Program_Error is not raised). Ergo, no one can make any assumptions about them. And a compiler can do anything it wants (including making the optimization you suggest work). Janus/Ada specifically makes no attempt to preserve any IEEE math (it looks insane to me) - we only worry about meeting the Annex G requirements of Ada. If you truly need IEEE math, you'll have to use some other Ada compiler. (As always, some customer could show up with enough money to encourage me to care, but that hasn't happened to date.) (3) Janus/Ada does essentially no floating point optimizations because pretty much anything runs afoul of accuracy problems. That means it has terrible floating point performance (again, something that hasn't mattered to our customers in general). I recently recompiled a float intensive Janus/Ada program with GNAT, and the runtime of approximately 48 hours with Janus/Ada dropped to about 30 minutes with GNAT. (Needless to say, I've stopped using the Janus/Ada version of that program.) Again, if we had customers for which this mattered a lot, we'd work on it, but that hasn't been true to date and there are a lot of other things competing for our time. Randy.