<font size=2 face="sans-serif">2014/07/15, 12:00 EST:</font>
<br><font size=2 face="sans-serif"> <b>Attendees</b>: Rajan, Jim,
David, Fred, Mike, Ian</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: SUBSTITUTEXOR
-> SUBSTITUTE_XOR. Pending issue resolution. - Leave open</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 ... - Done</font>
<br><font size=2 face="sans-serif"> David: Syntax.txt: Semantics:
Change exception1/exception2 to exceptions1/exceptions2 - Done</font>
<br><font size=2 face="sans-serif"> David: Syntax.txt: Add
to the end of the document other ideas considered. - Done</font>
<br><font size=2 face="sans-serif"> David: Syntax.txt: Add
a sentence to handle thread and object state considerations. - Done</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).
- Done</font>
<br>
<br><font size=2 face="sans-serif"> <b>Next Meeting</b>:</font>
<br><font size=2 face="sans-serif"> August 14th (Thursday),
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"> Rajan: Check part 2 ballot
status (at least for Canada) - Done: Vote closed on June 2nd for Canada.
Canada voted approve with no comments.</font>
<br><font size=2 face="sans-serif"> David: Survey the C standard
to see how much would need to change to support try/catch.</font>
<br><font size=2 face="sans-serif"> David: Talk to Douglas
to see if there are other concerns with try/catch.</font>
<br><font size=2 face="sans-serif"> All: Look for another
form for attributes to code other than try/catch or pragmas.</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: Supposed to be
published today.</font>
<br>
<br><font size=2 face="sans-serif"> Part 2: *ToDo: Rajan:
Check on status when internet access is available.</font>
<br>
<br><font size=2 face="sans-serif"> Part 3: PDTS ballot issued.
US vote: 12/0/0</font>
<br>
<br><font size=2 face="sans-serif"> Part 4: PDTS ballot issued.
US vote: 12/0/0</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Jim is making changes
to parts 2-4 to match what ISO changed for part 1.</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 color=blue 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 color=blue face="sans-serif">http://www.validlab.com/cfp/syntax.txt</font></a>
<br><font size=2 face="sans-serif"> Blaines note: Any
tests and branches will result in a lot of rework for one pass compilers.</font>
<br><font size=2 face="sans-serif"> Expected that setting
and handling traps will be the common implementation.</font>
<br><font size=2 face="sans-serif"> WG14 comment summary:</font>
<br><font size=2 face="sans-serif"> Don't like
pragma.</font>
<br><font size=2 face="sans-serif"> Don't want
try/catch unless it is the same as C++.</font>
<br><font size=2 face="sans-serif"> FE exception
handler.</font>
<br><font size=2 face="sans-serif"> David: Should be
useful for optimization for making the common case fast, and only check
the exceptional cases.</font>
<br><font size=2 face="sans-serif"> David: Note that
this would help a lot for R's underlying implementation helping big data.</font>
<br><font size=2 face="sans-serif"> David: Exception
handler clutters up the normal case.</font>
<br><font size=2 face="sans-serif"> Go with fe_try/fe_catch
allowing fe_patch, fe_substitute with changes for one pass compilers.</font>
<br><font size=2 face="sans-serif"> Note: We would
need to go through the C standard to find all the places to put in the
syntax.</font>
<br><font size=2 face="sans-serif"> ToDo: David to
survey the C standard to see how much would need to change to support try/catch.</font>
<br><font size=2 face="sans-serif"> ToDo: David to
talk to Douglas to see if there are other concerns with try/catch.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Should automatic
exception handling propagate to called functions? For example, rounding
modes are not for externally compiled CU's.</font>
<br><font size=2 face="sans-serif"> We could make it
undefined, propagate it, or not propagate it.</font>
<br><font size=2 face="sans-serif"> Implementation
wise, with hardware traps, propagating makes sense. For tests, not propagating
makes sense.</font>
<br><font size=2 face="sans-serif"> For CU's where
you don't have the code and hence can't recompile, it can be impossible
to set the tests.</font>
<br><font size=2 face="sans-serif"> Fits in with the
rounding directions as well if we make it not propagate.</font>
<br><font size=2 face="sans-serif"> Can we have a function
attribute type thing that allows the function to be called with and without
propagating contexts.</font>
<br><font size=2 face="sans-serif"> This would
be another complication to add, so maybe we can make it an extension or
as a possible future enahncement.</font>
<br><font size=2 face="sans-serif"> Can FE_ENV
access pragma's handle this?</font>
<br><font size=2 face="sans-serif"> Does
not seem to.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Precedence:</font>
<br><font size=2 face="sans-serif"> try/catch
can nest and work with parent blocks.</font>
<br><font size=2 face="sans-serif"> pragma can
be file scope and try/catch can override it for example.</font>
<br><font size=2 face="sans-serif"> Outer level
can be for all exceptions, inner can be only for invalid, while another
inner (or sibling) could be for divide by zero.</font>
<br><font size=2 face="sans-serif"> For exception
vs subexception, the more specific one should have precendence and would
be the only one executed. No throws allowed.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Abrupt underflow
and presubstition do not apply for catch blocks. Note that we still need
to work with optimization and rounding modes and other things. More than
a try, it is instead special handling code.</font>
<br><font size=2 face="sans-serif"> Currently this
all fits in with pragmas but it seems WG14 doesn't like them.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Note that the try/catch
can be converted to pragmas or vice versa rather than having both. Or a
third type of syntax with similar semantics.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> ToDo: All: Look
for another form for attributes to code other than try/catch or pragmas.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Implementation:</font>
<br><font size=2 face="sans-serif"> The Sun
model is good reference for implementation but not for users.</font>
<br><font size=2 face="sans-serif"> Sub-exception
can be tests while exceptions can be traps with possibly the trap handler
checking for sub-exceptions. Motorola and ppc did split the invalid exceptions
up, but this is likely not common amongst other implementations (ex. x86).</font>
<br><font size=2 face="sans-serif"> Can set
a side structure that is updated per operation, and then the handler can
look up the sub-exception in that structure.</font>
<br><font size=2 face="sans-serif"> Some are
function based so the opcode is not enough.</font>
<br><font size=2 face="sans-serif"> Is the next
instruction or other information available to trap handlers?</font>
<br><font size=2 face="sans-serif"> Normally
the register image is given to the handler. Can walk up the stack to see
__func__ for the function name to determine if it is one of those sub-exceptions.</font>
<br><font size=2 face="sans-serif"> Deferred
would almost have to be flags and hence high level exceptions not necessarily
sub-exceptions.</font>
<br><font size=2 face="sans-serif"> This
can be implementation defined (the sub-exception support).</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>