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: 22 Sep 93 21:07:25 GMT From: eachus@mitre-bedford.arpa (Robert I. Eachus) Subject: Re: Bug in AdaEd??? Message-ID: List-Id: In article <1993Sep22.093656.20606@sei.cmu.edu> firth@sei.cmu.edu (Robert Firth ) writes: > Indeed a nasty example! However, isn't the solution fairly simple: > eliminate the variable Junk and rewrite the test as > if X*Y > 10_000 then ... > As far as I can see, that has to work regardless of whether X*Y > overflows. Moreover, isn't it the obvious way to write the code? That was where we started...I guess I should have used a larger number in the example. Substitute 1_000_000 for 10_000 and compile your code on a 16-bit machine. Do you see the problem? The compiler is allowed to assume the expression is false in all cases without doing the check, and thus without raising NUMERIC_ERROR or CONSTRAINT_ERROR on the expression evaluation. Comparing a variable to a bound is not a problem, it's this pesky case of an expression whose value may be out of range of the type. Assigning the expression to a variable seems like the solution, but as my original example pointed out, that is not guarenteeed to work either. In practice, for anyone who has to write code like this, assigning to a global variable, or using pragma VOLITILE on the variable, etc. works fine. You get unoptimized code, but in this case that is precisely what you want. (And also, this is not just an Ada problem. I have also run into this "feature" in PL/I and FORTRAN compilers as well. In all cases confusing the optimizer was enough to get working code. The worry in the ARG is that optimizers are contantly getting smarter.) -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is...