<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;"><br><div><div>Our job in Part 5 is to specify (and get approved) the best C binding we can for what 754-2008 recommends for (among other things) alternate exception handling. The current C facilities for managing exception flags don’t provide all that 754-2008 recommends.</div><div><br></div><div>With the current C model one can write code to deal with exceptions, like</div><div><br></div><div>{</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>#pragams STDC FENV_ACCESS ON</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>fenv_t env;</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>feholdexcept(&env, FE_INVALID);</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>… main case code …</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>if (fetestexcept(FE_INVALID) {</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>… handle invalid case …</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>feclearexcept(FE_INVALID);</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>}</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>feupdateenv(&env);</div><div>}</div><div><br></div><div>Subexceptons could be added in the obvious way.</div><div><br></div><div>Other limitation of this approach are not so easily addressed (as noted by David and others in previous email):</div><div><br></div><div>With this approach, the user has to work with flags (and the tedious details of the feholdexcept and feupdateenv functions), instead of exceptions which are arguably the more natural concept and what 754-2008 alternate exception handling refers to. </div><div><br></div><div>This approach doesn’t support ASAP exception handling. All of the main case code executes, even if an exception occurs early. This might be addressed by sprinkling fetestexcept calls through the main case code, but that would slow done the presumably ordinary case when an invalid exception does not occur, and would further clutter the code. Effective placement of the flag tests would require implementation-specific knowledge about the efficiency of accessing flags.<br><br></div><div>This approach cannot be used to detect exact underflow exceptions (which do not raise flags).<br><br></div><div>The implementation can not take advantage of HW traps or special instructions that might allow more efficient handling of exceptions.</div><div><br></div><div>An approach with more try-catch like semantics (as we’ve been discussing the past few weeks) can provide a binding for more of what 754-2008 recommendations. I don’t think we’ve converged on a syntax. David has mostly completed a note we can send to WG14 to ask for input on what syntax might be acceptable. For our teleconference this Thursday, I suggest we try to resolve any issues that are blocking getting this note completed.</div><div><br></div><div>-Jim</div><div><br style="font-size: 13px;"><div style="font-size: 13px;"><br></div></div><div>On Jun 9, 2014, at 6:14 AM, Rajan Bhakta <<a href="mailto:rbhakta@us.ibm.com">rbhakta@us.ibm.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><font size="2" face="sans-serif">Not to derail the discussion, but Fred's
point about interaction with the existing C support for signal handlers
leads to the thoughts of the existing C support for (floating point) exceptions
in 7.6.2.</font>
<br>
<br><font size="2" face="sans-serif">I can't recall (nor can I find in my
notes) any discussion about extending what is already in the C standard
for floating point exceptions.</font>
<br>
<br><font size="2" face="sans-serif">Although arguably not as convenient
as what we are discussing right now, can we not add in new macros as we
are already discussing for the floating point exceptions, and use the existing
feclearexcept, fegetexceptflag, feraiseexcept, fesetexceptflag, and fetestexcept
functions? </font>
<br>
<br><font size="2" face="sans-serif">The example code given in the standard
shows how to do pretty much everything we are discussing, though more verbosely.</font>
<br>
<br><font size="2" face="sans-serif">The advantages are that it is building
on something that is already in the C standard and hence more easily accepted
by both the C committee, implementers and users due to its familiarity,
and avoids "ugly" pragmas. Also, the signal handling issue falls
under the current C standard model so we do not need to specify anything
extra here (whereas we would for the try-catch/pragma style model).</font>
<br>
<br><font size="2" face="sans-serif">The disadvantages are that it is not
as "clean" as the C++ style exception handling, it may make it
harder for optimizing compilers to recognize the exception pattern (though
I would argue it is actually easier on the compiler and hardware with the
current C standard way), and in a non-optimizing case, may be much slower
on some hardware.</font>
<br>
<br><font size="2" face="sans-serif">Now there may be the issue of lack of
bits (given exceptions are stored in int's from the interface) on some
implementations, but that can be worked around (ex. version check, or even
a new set of functions created for these new sub-exceptions).</font>
<br>
<br><font size="2" face="sans-serif">Regards,<br>
<br>
Rajan Bhakta<br>
z/OS XL C/C++ Compiler Technical Architect<br>
ISO C Standards Representative for Canada<br>
C Compiler Development<br>
Contact: <a href="mailto:rbhakta@us.ibm.com">rbhakta@us.ibm.com</a>, Rajan Bhakta/Houston/IBM</font>
<br>
<br>
<br>
<br><font size="1" color="#5f5f5f" face="sans-serif">From:
</font><font size="1" face="sans-serif">"Fred J. Tydeman"
<<a href="mailto:tydeman@tybor.com">tydeman@tybor.com</a>></font>
<br><font size="1" color="#5f5f5f" face="sans-serif">To:
</font><font size="1" face="sans-serif">"<a href="mailto:cfp-interest@ucbtest.org">cfp-interest@ucbtest.org</a>"
<<a href="mailto:cfp-interest@ucbtest.org">cfp-interest@ucbtest.org</a>>, </font>
<br><font size="1" color="#5f5f5f" face="sans-serif">Date:
</font><font size="1" face="sans-serif">06/06/2014 10:37 PM</font>
<br><font size="1" color="#5f5f5f" face="sans-serif">Subject:
</font><font size="1" face="sans-serif">Re: [Cfp-interest]
draft of syntax discussion for C committee</font>
<br><font size="1" color="#5f5f5f" face="sans-serif">Sent by:
</font><font size="1" face="sans-serif"><a href="mailto:cfp-interest-bounces@oakapple.net">cfp-interest-bounces@oakapple.net</a></font>
<br>
<hr noshade="">
<br>
<br>
<br><tt><font size="2">On Fri, 6 Jun 2014 16:25:15 -0700 (PDT) David Hough
CFP wrote:<br>
><br>
> #pragma STDC catch_fe fe_exception1 label1<br>
> #pragma STDC catch_fe fe_exception2 label2<br>
<br>
What is the interaction between this idea and<br>
a signal handler for SIGFPE?<br>
<br>
<br>
---<br>
Fred J. Tydeman Tydeman Consulting<br>
<a href="mailto:tydeman@tybor.com">tydeman@tybor.com</a> Testing, numerics, programming<br>
+1 (775) 287-5904 Vice-chair of PL22.11 (ANSI "C")<br>
Sample C99+FPCE tests: </font></tt><a href="http://www.tybor.com/"><tt><font size="2">http://www.tybor.com</font></tt></a><tt><font size="2"><br>
Savers sleep well, investors eat well, spenders work forever.<br>
<br>
_______________________________________________<br>
Cfp-interest mailing list<br>
<a href="mailto:Cfp-interest@oakapple.net">Cfp-interest@oakapple.net</a><br>
</font></tt><a href="http://mailman.oakapple.net/mailman/listinfo/cfp-interest"><tt><font size="2">http://mailman.oakapple.net/mailman/listinfo/cfp-interest</font></tt></a><tt><font size="2"><br>
<br>
</font></tt>
<br>_______________________________________________<br>Cfp-interest mailing list<br><a href="mailto:Cfp-interest@oakapple.net">Cfp-interest@oakapple.net</a><br>http://mailman.oakapple.net/mailman/listinfo/cfp-interest<br></blockquote></div><br></body></html>