Re: Bug in AdaEd???

[news.bu.edu!inmet!spock!stt@purdue.edu (Tucker Taft)]

In article <CDrELy.B1E@yktnews.watson.ibm.com> ncohen@watson.ibm.com writes:

>In article <CDr7CH.C9x@crdnns.crd.ge.com>, 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