[Cfp-interest] (SC22WG14.13401) Fwd: What syntax should be used to express IEEE 754-2008 alternate exception handling in C?

[Jim Thomas]

The specification for IEC 60559 alternate exception handling is static. Calls to user functions are not affected by alternate exception handling. Thus an FE2 exception raised by helper1 does not get the handling of FE2 exceptions specified in the other function.

-Jim

On Aug 5, 2014, at 3:27 PM, Blaine Garst <blaine at mac.com> wrote:

> The notion of FE cleanup across several frames is interesting independent of C++ exception machinery.
> 
> Consider
> 
> float helper1(float *array1, float *array2, size_t count) {
>    fe_try(FE1) {
>       ….     // some operation that raises FE2
>      result = ….
>   }
>   fe_catch(FE1) {
>      return 1.0F;
>   }
>   return result;
> }
> 
> float do_float_computations(float *array1, float *array2, size_t count) {
>     fe_try(FE2) {
>         float interim2 = helper1(array1, array2, count);  // FE2 raised in helper1
>         …
>         result = … interim2… ;
>      }
>      fe_catch(FE2) {
>           printf(“FE2 raised in helper1\n”);     // does this happen?
>           result = 1.0F;
>      }
>      return result;
> }
> 
> I’m unclear on what is possible and what is intended.  Is it the intent that “FE2 raised in helper1\n” ever be printed?  If it is the case, it seems onerous!!!
> 
> If it is not the intent, then I don’t think there are any frame cleanup issues that would collide with C++ exceptions.  Hardware traps would use a per-thread frame recovery pointer set up and torn down as part of each try/catch/catch block.
> 
> 
> 
> Blaine
> 
> 
> On Aug 5, 2014, at 2:10 PM, Jim Thomas <jaswthomas at sbcglobal.net> wrote:
> 
>> From Hans Boehm ...
>> 
>> Begin forwarded message:
>> 
>>> From: Hans Boehm <boehm at acm.org>
>>> Subject: Re: (SC22WG14.13396) What syntax should be used to express IEEE 754-2008 alternate exception handling in C?
>>> Date: August 5, 2014 at 10:08:42 AM PDT
>>> To: Jim Thomas <jaswthomas at sbcglobal.net>
>>> 
>>> Hi Jim,
>>> 
>>> I haven't been following this discussion closely enough, but wanted to express some vague uneasiness about adding another exception handling mechanism to C.  We already have Posix thread cancellation, and some code has to deal with C++ exceptions.  Correct programs in theory have to deal with all of these by providing clean-up actions that are compatible with any kind of exception that might pass through a particular function frame.  Having to deal with more than one kind of exception seems somewhere between ugly and intractable.
>>> 
>>> In my opinion, Posix thread cancellation is broken enough that I would love to see it replaced by something that looks more like C++ exceptions.  But that opinion is not universally shared, and the Posix folks seem quit attached to it.
>>> 
>>> Thanks.
>>> 
>>> Hans
>>> (Also now officially retired from HP, but really at Google)
>>> 
>>> 
>>> On Wed, Jul 23, 2014 at 9:23 AM, Jim Thomas <jaswthomas at sbcglobal.net> wrote:
>>> 
>>> On Jul 23, 2014, at 9:08 AM, Jens Gustedt <jens.gustedt at inria.fr> wrote:
>>> 
>>> > Hello
>>> > (sorry for the previous unfinished mail)
>>> >
>>> > Am Mittwoch, den 23.07.2014, 08:50 -0700 schrieb Jim Thomas:
>>> >> 1. fetestexcept does not distinguish sub exemptions (FE_INVALID_ADD,
>>> >> FE_INVALID_SNAN, etc.), as IEEE 754 specifies to be done.
>>> >
>>> > If the two specifications don't agree, we have a serious
>>> > problem. Maybe they could be made consistent by having FE_INVALID as
>>> > bit-or of the subcases?
>>> >
>>> >> 2. fetestexcept does not detect all occurrences of IEEE 754 underflow,
>>> >> because exact underflows do set the underflow flag, though they are
>>> >> underflows.
>>> >
>>> > I am not sure that I follow, can you please elaborate?
>>> 
>>> Per IEEE 754, an underflow exception occurs (with the intention that a trap occurs if traps are supported) when a tiny nonzero result is detected . If (and only if) also the rounded result is inexact, then the underflow flag is raised.
>>> -Jim
>>> 
>>> >
>>> > Jens
>>> >
>>> > --
>>> > :: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
>>> > :: ::::::::::::::: office Strasbourg : +33 368854536   ::
>>> > :: :::::::::::::::::::::: gsm France : +33 651400183   ::
>>> > :: ::::::::::::::: gsm international : +49 15737185122 ::
>>> > :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
>>> >
>>> >
>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20140805/85e21cd3/attachment-0001.html