Re: Bug in AdaEd???

[eachus@mitre-bedford.arpa (Robert I. Eachus)]

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...