<font size=2 face="sans-serif">2014/06/12, 12:00 EST:</font>
<br>
<br><font size=2 face="sans-serif"> <b>Attendees</b>: Rajan, Fred,
Marius, David, Jim, Ian, Mike</font>
<br>
<br><font size=2 face="sans-serif"> <b>New agenda items</b>:</font>
<br><font size=2 face="sans-serif"> None.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> <b>Old action items</b>:</font>
<br><font size=2 face="sans-serif"> David: Part 5: (From last
meeting): Complete exception specification with the full syntax dealing
with scope and sub-exceptions. Include a discussion document with reasons
choices and alternatives. - Partially done (more of an outline. Sent on
2014/05/12). Keep open.</font>
<br><font size=2 face="sans-serif"> David: Part 5: For fast_subnormal,
change to "allows abrupt underflow" -> "allows (but not
requires) abrupt underflow". Done.</font>
<br><font size=2 face="sans-serif"> David: Part 5: Put in
exception category in the sub-exceptions as the prefix. Ex. FE_DIV_ZERO
-> FE_DIVBYZERO_DIVIDES. Done.</font>
<br><font size=2 face="sans-serif"> David: Part 5: Add in
FE_INVALID_OTHER and FE_DIVBYZERO_OTHER. Done.</font>
<br><font size=2 face="sans-serif"> David: Part 5: OPTFLAG
-> MAY_FLAG, NOFLAG -> NO_FLAG, SUBSTITUTEXOR -> SUBSTITUTE_XOR.
Done first two, last is pending issue resolution.</font>
<br>
<br><font size=2 face="sans-serif"> <b>Next meeting</b>:</font>
<br><font size=2 face="sans-serif"> July 15th (Tuesday), 2014,
12:00 EST, 9:00 PDT</font>
<br><font size=2 face="sans-serif"> Same teleconference number.</font>
<br>
<br><font size=2 face="sans-serif"> <b>New action items</b>:</font>
<br><font size=2 face="sans-serif"> David: Syntax.txt: Add
in the beginning something that gives the purpose of the document. Ex.
The CFP group is asking for feedback from WG14 for ...</font>
<br><font size=2 face="sans-serif"> David: Syntax.txt: Semantics:
Change exception1/exception2 to exceptions1/exceptions2</font>
<br><font size=2 face="sans-serif"> David: Syntax.txt: Add
to the end of the document other ideas considered.</font>
<br><font size=2 face="sans-serif"> David: Syntax.txt: Add
a sentence to handle thread and object state considerations.</font>
<br><font size=2 face="sans-serif"> David: Syntax.txt: Add
a sentence about ASAP vs deferred exception handling (try-catch vs try-patch).</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> <b>Discussion</b>:</font>
<br><font size=2 face="sans-serif"> Part 1: Reviewing draft
as edited by ISO. Jim has sent back comments on changes made.</font>
<br>
<br><font size=2 face="sans-serif"> Part 2: DTS ballot issued.</font>
<br>
<br><font size=2 face="sans-serif"> Part 3: PDTS ballot issued.</font>
<br>
<br><font size=2 face="sans-serif"> Part 4: PDTS ballot issued.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Part 5: (Email discussion
based) (</font><a href=http://www.validlab.com/cfp/*.txt><font size=2 face="sans-serif">http://www.validlab.com/cfp/*.txt</font></a><font size=2 face="sans-serif">)</font>
<br><font size=2 face="sans-serif"> </font><a href=http://www.validlab.com/cfp/syntax.txt><font size=2 face="sans-serif">http://www.validlab.com/cfp/syntax.txt</font></a>
<br><font size=2 face="sans-serif"> *ToDo: David:
Add in the beginning something that gives the purpose of the document.
Ex. The CFP study group is asking for feedback from WG14 for ...</font>
<br><font size=2 face="sans-serif"> *ToDo: David:
Semantics: Change exception1/exception2 to exceptions1/exceptions2</font>
<br><font size=2 face="sans-serif"> Should we
add the other things we considered like:</font>
<br><font size=2 face="sans-serif"> 1)
PL/I, Basic and other languages "ON event DO/GOTO/GOSUB handler"</font>
<br><font size=2 face="sans-serif"> 2)
Exception handler callback function registration (like signal handlers)</font>
<br><font size=2 face="sans-serif"> 3)
Using SIGFPE signal handling</font>
<br><font size=2 face="sans-serif"> 4)
Testing flags with the existing C floating point environment handling functions
and adding in new flags like underflow</font>
<br><font size=2 face="sans-serif"> at the end
of the document? Yes</font>
<br><font size=2 face="sans-serif"> *ToDo: David:
Add to the end of the document other ideas considered.</font>
<br><font size=2 face="sans-serif"> Mike: Avoiding
extra nesting is advantageous if we don't do try/catch.</font>
<br><font size=2 face="sans-serif"> Fred: How
does what we do work with threads and object state?</font>
<br><font size=2 face="sans-serif"> Rajan:
Should be written/stored to variables in the scope of the exception handling
be in an indeterminate state only?</font>
<br><font size=2 face="sans-serif"> Rajan:
Also side effects are not known in sequencing.</font>
<br><font size=2 face="sans-serif"> Yes,
we should cover both cases for object state.</font>
<br><font size=2 face="sans-serif"> For
threads, this (exception handling) should be thread local like the existing
C Standard floating point environment being thread local.</font>
<br><font size=2 face="sans-serif"> Fred:
Signal handling in a multi-threaded program results in undefined behaviour.</font>
<br><font size=2 face="sans-serif"> David will
make the changes discussed and post it for review before sending it out
to the wider WG14 group.</font>
<br><font size=2 face="sans-serif"> Substitution (pre/xor):</font>
<br><font size=2 face="sans-serif"> David: Haven't
looked at pre-substitution since it is cheaper to do exception/test-and-branch.</font>
<br><font size=2 face="sans-serif"> Ex.
Instead of "SUBSTITUTE(z = x / y, DIV_ZERO, z = x' / y')" do
"try { z = x / y; } catch (DIV_ZERO) { z = x' / y' }"</font>
<br><font size=2 face="sans-serif"> Easier to
get one set of changes made rather than new syntax for each part with their
attendant issues and potential problems. This means the exception handling
approach is better.</font>
<br><font size=2 face="sans-serif"> Raise-no-flag:</font>
<br><font size=2 face="sans-serif"> David: Requires
trapping, otherwise flags would be raised.</font>
<br><font size=2 face="sans-serif"> Shows that
the programmer has explicitly thought about the flags. i.e. opt-out vs
opt-in</font>
<br><font size=2 face="sans-serif"> Can be done
with a pragma or try/catch (if catch does not raise a flag for the caught
exception).</font>
<br><font size=2 face="sans-serif"> We can document
how to use the exception handling (ex. try-catch) to handle a lot of these
items (substitution, may-flag, raise-no-flag, etc.).</font>
<br><font size=2 face="sans-serif"> Should we have
two versions (asap-try-catch vs try-catch)? An ASAP and a deferred one?</font>
<br><font size=2 face="sans-serif"> Perhaps
have different catch's? catch vs deferred_catch/patch or a #pragma that
identifies the following code as ASAP or not.</font>
<br><font size=2 face="sans-serif"> Loops (indeterminate
or large limits) may want to do asap while smaller ones may want deferred.
Should we give the compiler hints or directives for this?</font>
<br><font size=2 face="sans-serif"> We should
do both mechanisms since not doing asap means you can use the flag checking
instead.</font>
<br><font size=2 face="sans-serif"> catch can
be implemented in patch, except for exact underflow</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>