[J3] [EXTERNAL] Re: Exception handling in one Ada processor

[Van Snyder]

On Thu, 2019-07-25 at 18:30 +0000, Bill Long via J3 wrote:
> > On Jul 25, 2019, at 1:05 PM, William Clodius via J3 <j3 at mailman.j3-fortran.org> wrote:
> > 
> > What has struck me the most about Van’s recent postings on this
> topic is that his examples seem to be focused on detecting user errors
> (square root of a negative number, out of bounds indexing, overflow,
> etc.). This strikes me as odd in that about the only thing I can think
> of doing for such errors is reporting the type of error, its location,
> and the associated call chain, something I can do now by setting the
> pertinent compiler flags.
> 
> Excellent point.  And, when setting the flags, you are intentionally
> accepting a performance hit for the benefit of debugging your code.
> For production running, you can recompile without the flags and get
> performance back. 

Exception handling isn't only for debugging.  The example in my paper
caught overflow or underflow to allow computing the L2 norm of a vector
by the obvious (and fast) method, unless an overflow or underflow
occurs.  Without exceptions, one needs to use the slower method that
checks at every step.  Whether overflow or underflow will occur during
computation of an L2 norm usually depends upon input data.  It's not a
topic that can be examined in a few cases of debugging, and then ignored
in production.

> The things that are not already covered by existing facilities are the
> hard ones - system errors like segfault or running out of memory.
> Maybe the solution is a mechanism for registering system error
> handlers, though that is a bit out of typical scope for the standard, 
> 
> Cheers,
> Bill
> 
> 
> 
> > I do not typically see any way for the user to usefully handle such errors. Do users really want an exception handling system, or do they want a well defined error reporting mechanism?
> > 
> > Sent from my iPad
> > 
> > On Jul 25, 2019, at 6:32 AM, Van Snyder via J3 <j3 at mailman.j3-fortran.org> wrote:
> > 
> >> I've just had some correspondence from the developer of Janus/Ada.
> >> 
> >> He told me that having exception handlers in a program increases the binary image size.  The fixed amount of increase, due to the presence of exception handling in the language, consists of a small runtime library component.  The rest of the increase is code in exception handlers.  If there are no handlers, there is no code to implement them, and the binary image size increase is limited to the runtime library component.
> >> 
> >> The Ada specification of exception handling does not introduce sequence points.  He wrote that in
> >> 
> >>   A := <expr1>;
> >>   B := <expr2>;
> >> 
> >> if an exception occurs during evaluation of <expr1>, there is no guarantee that <expr2> was not evaluated or that B was not updated, and if an exception occurs during evaluation of <expr2> there is no guarantee that <expr1> was evaluated and A updated.  The processor is able to re-order those statements, according to the usual rules that would apply in the absence of exception handling facilities.  Loop-invariant calculations could be hoisted out of loops.  The only restriction on code motion is that code inside one begin ... handle ... end block cannot be moved outside the block (or into it).
> >> 
> >> He continued
> >> 
> >> I think such a rule is absolutely required if exceptions are implemented (at least with any sort of language-defined checks like bounds checks or overflow checks). Otherwise, the code has to be compiled in a strict order which would make most optimizations impossible (and even dead code elimination). *That* would be a problem!
> >> 
> >> If C++ exception handling has different effects, we definitely should not copy it.  It should serve primarily as a cautionary tale.
> >> 
> 
> Bill Long                                                                       longb at cray.com
> Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
> Bioinformatics Software Development                      fax:  651-605-9143
> Cray Inc./ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425
> 
>