From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 23 Sep 93 20:55:55 GMT From: news.bu.edu!inmet!spock!stt@purdue.edu (Tucker Taft) Subject: Re: Bug in AdaEd??? Message-ID: List-Id: In article ncohen@watson.ibm.com writes: >In article , groleau@e7sa.crd.ge.com >(Wes Groleau x1240 C73-8) writes: > >|> Language lawyers please explain in short words if I'm wrong, but I can't >|> for the life of me think of ANY reason why optimization of code with >|> predetermined results would intentionally be done to give different results ! > >Here is a summary of RM 11.6 "while standing on one foot": > > An optimizer is allowed to assume that the intended effect of a > program is not to raise a predefined exception. > Well, as indicated in another response I made, I believe an even more important "standing on one foot" rule is: "language-defined checks are designed to prevent junk output" That is, rather than just wrapping around on overflow, or trashing random memory which later gets used in producing the answer, the language-defined checks catch such transgressions so that *if* a program produces output, the output corresponds to a common-sense interpretation of the source of the program. Of course, checks can't prevent junk output from junk programs (that would violate the most holy rule of garbage-in-garbage-out), but they can prevent junk output due to wild stores, wild jumps, and numeric overflow. The purpose of 11.6, in my view, was to allow a computation that might fail a language-defined check to be treated like any other computation from the point of view of optimization (reordering, common subexpressions, dead code elimination, etc.). If some check does ultimately fail during execution of the optimized code, the exception doesn't need to look like it emanated from exactly where it would if the source code was translated literally by the compiler. The compiler is allowed to do all kinds of transformations so long as they preserve correct results, *and so long as they don't produce junk output.* In other words, exceptions don't have to be "precise," but they jolly well better happen if the alternative is junk output. As pointed out in my other response in this thread, one "solution" to this problem seems to be to have compilers treat a computation that fails a language-defined check as producing an "undefined value" (aka "bottom"). In some hypothetical hardware, each type would actually allow for an undefined value in addition to all the other values of the type. The net effect of 11.6 is that the exception need not be raised when an undefined value is calculated, but it must be raised before an undefined value finds its way into the output of the program (and if there are handlers for the corresponding exception, the handler governing the sequence of statements containing the failing computation must get control). >Norman H. Cohen ncohen@watson.ibm.com S. Tucker Taft Ada 9X Mapping/Revision Team Intermetrics, Inc. Cambridge, MA 02138