<font size=2 face="sans-serif">Just to make sure what we are doing is
intended, I recall from the last meeting we decided not to go with the
try/catch style due to the opinion it would be a hard sell to the C committee
(and likely C compiler vendors as well).</font>
<br>
<br><font size=2 face="sans-serif">Have we decided to change that approach
or are we still just making proposals in case the #pragma or macro magic
does not work?</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: rbhakta@us.ibm.com, 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">Ian McIntosh <ianm@ca.ibm.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">cfp-interest@ucbtest.org,
</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">05/29/2014 10:16 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [Cfp-interest]
more on try/catch</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">cfp-interest-bounces@oakapple.net</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=2 face="sans-serif">I thought I'd try approaching this from
the opposite direction: How would you change C++ to handle floating-point
exceptions? Then could / how could that be handled in C, and would
that also work in C++?</font><font size=3><br>
<br>
</font><font size=2 face="sans-serif"><br>
So far C++ exceptions only come from throw statements, never from floating-point
exceptions (also never from traps, other hardware detected events, or operating
system detected events). Let's assume that is changed so they can
come from floating-point exceptions.</font><font size=3><br>
</font><font size=2 face="sans-serif"><br>
In C++, a catch clause catches an exception object according to its type,
not its value, then is optionally told the value.<br>
- One way to use that is to define a "floating point exception"
struct type that contains something identifying which exception(s) happened
in the try block, and possibly information about the kind of operation
and the input value(s) triggering it, and catch would catch an object.<br>
- Another way is to have a separate type for each possible exception.<br>
- In C++ those could be merged using base and derived types.<br>
For any of those, we should also define how to handle implementation-defined
exceptions; for example, PowerPC has half a dozen specific kinds of invalid
operation exceptions plus a general flag combining them.</font><font size=3><br>
</font><font size=2 face="sans-serif"><br>
There are of course many variations but syntactically, so far it could
look like</font><font size=3><br>
</font><tt><font size=2><br>
try {<br>
. . . block of code . . .<br>
}<br>
catch (FPException::Overflow fpexception) { /* overflow handler */
. . . }<br>
#ifdef PPC<br>
catch (FPException::PowerPC_SignalingNaN fpexception) { /* SNaN handler
*/ . . . }<br>
catch (FPException::PowerPC_InvalidConversion fpexception) { /* Invalid
Conversion handler */ . . . }<br>
catch (FPException::PowerPC_SqrtOfNegative fpexception) { /* Sqrt
of Negative handler */ . . . }<br>
#endif<br>
catch (FPException::InvalidOperation fpexception) { /* General Invalid
Operation handler */ . . . }<br>
catch (FPException::ZeroDivide fpexception) { /* Divide Finite by
Zero handler */ . . . }<br>
catch (int m) { /* integer handler */ }<br>
catch (...) { /* handler for anything else */ }</font></tt><font size=3><br>
</font><font size=2 face="sans-serif"><br>
In each of the </font><tt><font size=2>FPException</font></tt><font size=2 face="sans-serif">
catch clauses, the "</font><tt><font size=2>fpexception</font></tt><font size=2 face="sans-serif">"
is like a function parameter containing the exception information, is optional,
and can be any name you choose.</font><font size=3><br>
</font><font size=2 face="sans-serif"><br>
A </font><tt><font size=2>catch</font></tt><font size=2 face="sans-serif">
clause can have a list of exception types if they all need the same handling.</font><font size=3><br>
</font><font size=2 face="sans-serif"><br>
This is only part of the solution. One issue is how the exceptions
to check are to be specified.</font><font size=3><br>
</font><font size=2 face="sans-serif"><br>
The rule could be that the floating-point exceptions to be checked for
would be those which have a catch clause naming them, but that's not true
for general C++ exceptions so would be an inconsistency. A portable
way to specify which ones to enable would be useful; for example it could
be a function like</font><tt><font size=2><br>
FPEnable oldcontrols = enableFPExceptions (FPEnable::Overflow | FPEnable::InvalidOperation
| FPEnable::ZeroDivide);</font></tt><font size=2 face="sans-serif"><br>
which sets up exception checking controls and returns the old exception
controls, along with another function to restore the saved controls afterwards</font><tt><font size=2><br>
restoreFPExceptions (oldcontrols);</font></tt><font size=2 face="sans-serif"><br>
Since a catch handler doesn't have access to the try block's local variables,
those would have to be outside the try block. They could be useful
elsewhere too.</font><font size=3><br>
</font><font size=2 face="sans-serif"><br>
In C++ an alternative would be that the control setting would construct
an object whose destructor would automatically do the restore (although
that wouldn't work for C which doesn't have constructors and destructors),
eg,</font><tt><font size=2><br>
{<br>
FPEnableExceptions oldcontrols (FPEnable::Overflow | FPEnable::InvalidOperation
| FPEnable::ZeroDivide);<br>
try . . .<br>
// At the end of this block the destructor FPEnableExceptions::~FPEnableExceptions
(oldcontrols) would be run,<br>
// restoring the old controls.<br>
}</font></tt><font size=3><br>
</font><font size=2 face="sans-serif"><br>
Assuming the first way (because it's more compatible with C), the combination
(with the </font><tt><font size=2>int</font></tt><font size=2 face="sans-serif">
and </font><tt><font size=2>...</font></tt><font size=2 face="sans-serif">
deleted) is</font><font size=3><br>
</font><tt><font size=2><br>
FPExceptionControls oldcontrols = enableFPExceptions (FPEnable::Overflow
| FPEnable::InvalidOperation | FPEnable::ZeroDivide);<br>
try {<br>
. . . block of code . . .<br>
}<br>
catch (FPException::Overflow fpexception) { /* overflow handler */
. . . }<br>
#ifdef PPC<br>
catch (FPException::PowerPC_SignalingNaN fpexception) { /* SNaN handler
*/ . . . }<br>
catch (FPException::PowerPC_InvalidConversion fpexception) { /* Invalid
Conversion handler */ . . . }<br>
catch (FPException::PowerPC_SqrtOfNegative fpexception) { /* Sqrt
of Negative handler */ . . . }<br>
#endif<br>
catch (FPException::InvalidOperation fpexception) { /* General Invalid
Operation handler */ . . . }<br>
catch (FPException::ZeroDivide fpexception) { /* Divide Finite by
Zero handler */ . . . }<br>
restoreFPExceptions (oldcontrols);</font></tt><font size=3><br>
<br>
</font><font size=2 face="sans-serif"><br>
What about C? C doesn't have </font><tt><font size=2>try</font></tt><font size=2 face="sans-serif">,
</font><tt><font size=2>throw</font></tt><font size=2 face="sans-serif">
or </font><tt><font size=2>catch</font></tt><font size=2 face="sans-serif">,
and doesn't have classes so the "</font><tt><font size=2>::</font></tt><font size=2 face="sans-serif">"
syntax wouldn't work, but possibly could have something like:</font><font size=3><br>
</font><tt><font size=2><br>
fpexceptioncontrols oldcontrols = enablefpexceptions (fpexception_overflow
| fpexception_invalidoperation | fpexception_zerodivide);<br>
try {<br>
. . . block of code . . .<br>
}<br>
catch (fpexception_overflow fpexception) { /* overflow handler
*/ . . . }<br>
#ifdef PPC<br>
catch (fpexception_powerpc_signalingnan fpexception) { /* SNaN
handler */ . . . }<br>
catch (fpexception_powerpc_invalidconversion fpexception) {
/* Invalid Conversion handler */ . . . }<br>
catch (fpexception_powerpc_sqrtofnegative fpexception) { /*
Sqrt of Negative handler */ . . . }<br>
#endif<br>
catch (fpexception_invalidoperation fpexception) { /* General
Invalid Operation handler */ . . . }<br>
catch (fpexception_zerodivide fpexception) { /* Divide Finite
by Zero handler */ . . . }<br>
restorefpexceptions (oldcontrols);</font></tt><font size=3><br>
</font><font size=2 face="sans-serif"><br>
A simpler example to just handle overflow would be</font><font size=3><br>
</font><tt><font size=2><br>
fpcontrols oldcontrols = enablefpexceptions (fpexception_overflow);<br>
try {<br>
. . . block of code . . .<br>
}<br>
catch (fpexception_overflow fpexception) { /* overflow handler
*/ . . . }<br>
restorefpexceptions (oldcontrols);</font></tt><font size=3><br>
</font><font size=2 face="sans-serif"><br>
It's more C than C++ style, but should work in C++ too. It doesn't
look much different from the proposal below.</font><font size=3><br>
</font><font size=2 face="sans-serif"><br>
>From an implementation point of view, the same approaches and the same
performance issues apply as in my earlier email. Optimizations like
saving and setting then later restoring exception controls can be moved
out of loops to reduce overhead.</font><font size=3><br>
</font><font size=2 face="sans-serif"><br>
This doesn't handle automatic value substitution, and like some of our
other approaches is a heavy approach where </font><tt><font size=2>block
of code</font></tt><font size=2 face="sans-serif"> is a simple expression,
but to me it seems fairly readable.</font><font size=3><br>
</font><font size=2 face="sans-serif"><br>
If C ever wanted to extend exception handling to allow </font><tt><font size=2>throw</font></tt><font size=2 face="sans-serif">s,
this is compatible with the C++ syntax and semantics. If C and/or
C++ ever wanted to extend exception handling to handle traps, other hardware
detected events, or operating system detected events, those could be extensions
of this.</font><font size=3><br>
</font><font size=2 face="sans-serif"><br>
- Ian McIntosh IBM Canada Lab
Compiler Back End Support and Development</font><font size=3><br>
<br>
<br>
</font><img src=cid:_1_07F0DFAC07F0B3D4004D0C7E86257CE8 alt="Inactive hide details for David Hough CFP ---2014-05-29 04:37:24 PM---Unlike normal C++ try blocks which can be compiled withou"><font size=2 color=#424282 face="sans-serif">David
Hough CFP ---2014-05-29 04:37:24 PM---Unlike normal C++ try blocks which
can be compiled without reference to whatever exceptions might be</font><font size=3><br>
</font>
<table width=100% style="border-collapse:collapse;">
<tr valign=top height=8>
<td width=30% style="border-style:solid;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><img src=cid:_1_07F0EE9407F0EAC0004D0C7E86257CE8 width=96 height=1>
<br><font size=1 color=#5f5f5f face="sans-serif">From:</font>
<td width=69% style="border-style:solid;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><img src=cid:_1_092F5C9807F0F5E8004D0C7E86257CE8 width=1 height=1><font size=1 face="sans-serif"><br>
David Hough CFP <pcfp@oakapple.net></font>
<tr valign=top height=8>
<td style="border-style:solid;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><img src=cid:_1_092F63C0092F5FC0004D0C7E86257CE8 width=96 height=1>
<br><font size=1 color=#5f5f5f face="sans-serif">To:</font>
<td style="border-style:solid;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><img src=cid:_1_092F6C0C092F680C004D0C7E86257CE8 width=1 height=1><font size=1 face="sans-serif"><br>
cfp-interest@ucbtest.org, </font>
<tr valign=top height=8>
<td style="border-style:solid;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><img src=cid:_1_092F71E4092F6E10004D0C7E86257CE8 width=96 height=1>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:</font>
<td style="border-style:solid;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><img src=cid:_1_092F7A04092F7630004D0C7E86257CE8 width=1 height=1><font size=1 face="sans-serif"><br>
2014-05-29 04:37 PM</font>
<tr valign=top height=8>
<td style="border-style:solid;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><img src=cid:_1_092F7FDC092F7C08004D0C7E86257CE8 width=96 height=1>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:</font>
<td style="border-style:solid;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><img src=cid:_1_092F87C8092F83F4004D0C7E86257CE8 width=1 height=1><font size=1 face="sans-serif"><br>
[Cfp-interest] more on try/catch</font>
<tr valign=top height=8>
<td style="border-style:solid;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><img src=cid:_1_092F8DA0092F89CC004D0C7E86257CE8 width=96 height=1>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:</font>
<td style="border-style:solid;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><img src=cid:_1_092F95C0092F91EC004D0C7E86257CE8 width=1 height=1><font size=1 face="sans-serif"><br>
cfp-interest-bounces@oakapple.net</font></table>
<br>
<hr noshade><font size=3><br>
<br>
</font><tt><font size=2><br>
<br>
Unlike normal C++ try blocks which can be compiled without reference to<br>
whatever exceptions might be caught, floating-point try blocks have to<br>
be compiled knowing what exceptions might be singled out for special<br>
treatment.<br>
<br>
So maybe fp try/catch<br>
should just be separated syntactically as<br>
well as semantically from C++:<br>
<br>
<br>
fe_try {<br>
}<br>
fe_catch_sub( e, elist) {<br>
}<br>
fe_catch_exceps( e, elist) {<br>
}<br>
fe_catch_flags( f, flist) {<br>
}<br>
<br>
I've added a new wrinkle - fe_catch_sub which computes a substituted<br>
value and continues execution. How is the substituted value
evaluated?<br>
It's the value of a compound statement - but it's undefined (and compilers<br>
ought to warn) if it uses any variables whose values change within the<br>
try block. Thus the try block to use with the substituted
value<br>
is probably pretty small. The substituted value can be presubstituted<br>
if there's system support for that, but in the much more likely event that<br>
there isn't, then the compiler has to generate appropriate tests and branches.<br>
The elist usually better be a list of one subexception of invalid<br>
rather than invalid itself;<br>
otherwise the compiler has to generate tests wherever a signaling NaN might<br>
cause an invalid exception. Do we need a nonstandard pragma
(meaning<br>
OK to ignore) that says compiler need not worry about signaling NaNs in
a<br>
given scope? Life would have been a lot simpler if signaling
NaNs had<br>
been given their own exception in 1977.<br>
<br>
The substitute-exor feature of 754-2008 can be provided by the above plus<br>
a standard function fe_exor_result(x,y,z) which returns abs(x) with the<br>
exor signs of y and z.<br>
<br>
_______________________________________________<br>
Cfp-interest mailing list<br>
Cfp-interest@oakapple.net</font></tt><tt><font size=2 color=blue><u><br>
</u></font></tt><a href="http://mailman.oakapple.net/mailman/listinfo/cfp-interest"><tt><font size=2 color=blue><u>http://mailman.oakapple.net/mailman/listinfo/cfp-interest</u></font></tt></a><tt><font size=2><br>
</font></tt><font size=3><br>
<br>
</font><tt><font size=2>_______________________________________________<br>
Cfp-interest mailing list<br>
Cfp-interest@oakapple.net<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>
</font></tt>
<br>