<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><div>The notion of FE cleanup across several frames is interesting independent of C++ exception machinery.</div><div><br></div><div>Consider</div><div><br></div><div>float helper1(float *array1, float *array2, size_t count) {</div><div> fe_try(FE1) {</div><div> …. // some operation that raises FE2</div><div> result = ….</div><div> }</div><div> fe_catch(FE1) {</div><div> return 1.0F;</div><div> }</div><div> return result;</div><div>}</div><div><br></div><div>float do_float_computations(float *array1, float *array2, size_t count) {</div><div> fe_try(FE2) {</div><div> float interim2 = helper1(array1, array2, count); // FE2 raised in helper1</div><div> …</div><div> result = … interim2… ;</div><div> }</div><div> fe_catch(FE2) {</div><div> printf(“FE2 raised in helper1\n”); // does this happen?</div><div> result = 1.0F;</div><div> }</div><div> return result;</div><div>}</div><div><br></div><div>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!!!</div><div><br></div><div>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.</div><div><br></div><div><br></div><div><br></div><div>Blaine</div><div><br></div><div><br></div><div>On Aug 5, 2014, at 2:10 PM, Jim Thomas <<a href="mailto:jaswthomas@sbcglobal.net">jaswthomas@sbcglobal.net</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">From Hans Boehm ...<br><div><br><div>Begin forwarded message:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family: Helvetica;"><b>From: </b></span><span style="font-family:'Helvetica';">Hans Boehm <<a href="mailto:boehm@acm.org">boehm@acm.org</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family: Helvetica;"><b>Subject: </b></span><span style="font-family:'Helvetica';"><b>Re: (SC22WG14.13396) What syntax should be used to express IEEE 754-2008 alternate exception handling in C?</b><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family: Helvetica;"><b>Date: </b></span><span style="font-family:'Helvetica';">August 5, 2014 at 10:08:42 AM PDT<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family: Helvetica;"><b>To: </b></span><span style="font-family:'Helvetica';">Jim Thomas <<a href="mailto:jaswthomas@sbcglobal.net">jaswthomas@sbcglobal.net</a>><br></span></div><br><div><div dir="ltr">Hi Jim,<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Thanks.</div><div><br></div><div>Hans</div><div>(Also now officially retired from HP, but really at Google)</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 23, 2014 at 9:23 AM, Jim Thomas <span dir="ltr"><<a href="mailto:jaswthomas@sbcglobal.net" target="_blank">jaswthomas@sbcglobal.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On Jul 23, 2014, at 9:08 AM, Jens Gustedt <<a href="mailto:jens.gustedt@inria.fr">jens.gustedt@inria.fr</a>> wrote:<br>
<br>
> Hello<br>
> (sorry for the previous unfinished mail)<br>
><br>
> Am Mittwoch, den 23.07.2014, 08:50 -0700 schrieb Jim Thomas:<br>
>> 1. fetestexcept does not distinguish sub exemptions (FE_INVALID_ADD,<br>
>> FE_INVALID_SNAN, etc.), as IEEE 754 specifies to be done.<br>
><br>
> If the two specifications don't agree, we have a serious<br>
> problem. Maybe they could be made consistent by having FE_INVALID as<br>
> bit-or of the subcases?<br>
><br>
>> 2. fetestexcept does not detect all occurrences of IEEE 754 underflow,<br>
>> because exact underflows do set the underflow flag, though they are<br>
>> underflows.<br>
><br>
> I am not sure that I follow, can you please elaborate?<br>
<br>
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.<br>
-Jim<br>
<br>
><br>
> Jens<br>
<span class="HOEnZb"><font color="#888888">><br>
> --<br>
> :: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::<br>
> :: ::::::::::::::: office Strasbourg : <a href="tel:%2B33%20368854536" value="+33368854536">+33 368854536</a> ::<br>
> :: :::::::::::::::::::::: gsm France : <a href="tel:%2B33%20651400183" value="+33651400183">+33 651400183</a> ::<br>
> :: ::::::::::::::: gsm international : <a href="tel:%2B49%2015737185122" value="+4915737185122">+49 15737185122</a> ::<br>
> :: <a href="http://icube-icps.unistra.fr/index.php/Jens_Gustedt" target="_blank">http://icube-icps.unistra.fr/index.php/Jens_Gustedt</a> ::<br>
><br>
><br>
<br>
</font></span></blockquote></div><br></div>
</div></blockquote></div><br></div></blockquote></div><br></body></html>