<font size=2 face="sans-serif">2014/08/14, 12:00 EST:</font>
<br><font size=2 face="sans-serif"> <b>Attendees</b>: Rajan, Jim,
David, Fred, Marius, Ian</font>
<br>
<br><font size=2 face="sans-serif"> <b>New agenda items:</b></font>
<br><font size=2 face="sans-serif"> Jacob Navia's note - Added</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> <b>Sticky/Keep open/Long term
action items:</b></font>
<br><font size=2 face="sans-serif"> David: Part 5: 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"> </font>
<br><font size=2 face="sans-serif"> <b>Lasts meeting action items:</b></font>
<br><font size=2 face="sans-serif"> Rajan: Check part 2 ballot
status (at least for Canada). - Done (Ballot passed)</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. - Done
(Note sent on 2014/07/25)</font>
<br><font size=2 face="sans-serif"> David: Talk to Douglas
to see if there are other concerns with try/catch. - Not done. Close the
item due to discussion to happen regarding part 5 today.</font>
<br><font size=2 face="sans-serif"> All: Look for another
form for attributes to code other than try/catch or pragmas. - Done</font>
<br>
<br><font size=2 face="sans-serif"> <b>New action items:</b></font>
<br><font size=2 face="sans-serif"> Rajan: Draft a response
to Jacob Navia's note and send it to the CFP group before sending it to
the wider WG14 group.</font>
<br><font size=2 face="sans-serif"> David: Part 5: Prepare
a complete specification for alternate exception handling by the end of
August.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> <b>Next Meeting:</b></font>
<br><font size=2 face="sans-serif"> September 16th (Tuesday),
2014, 12:00 EST, 9:00 PDT</font>
<br><font size=2 face="sans-serif"> Same teleconference number.</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: Published.</font>
<br>
<br><font size=2 face="sans-serif"> Part 2: DTS ballot is
done. Moving to publish to send to ISO for their ISO format edits.</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"> Jacob Navia's note on
2014/08/14 4:34AM CST:</font>
<br><font size=2 face="sans-serif"> *ToDo: Rajan: Draft
a response to Jacob Navia's note and send it to the CFP group before sending
it to the wider WG14 group.</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"> Based on the proposal
of going forward with #pragma's.</font>
<br><font size=2 face="sans-serif"> #pragma's allow
the optimization and other aspects as well so a single solution form.</font>
<br><font size=2 face="sans-serif"> Problem of scope
of expressions in the #pragma.</font>
<br><font size=2 face="sans-serif"> The scope
is for identifiers and area of application of the pragma (like the static
rounding mode).</font>
<br><font size=2 face="sans-serif"> Ex.
goto or substitution for an exception may have different scopes (exception
area vs identifier location).</font>
<br><font size=2 face="sans-serif"> Jim: Similar
to the function issue with the static rounding mode.</font>
<br><font size=2 face="sans-serif"> David: Nested
blocks could have overridden a label (or variable) name where the exception
could happen in the parent or child block.</font>
<br><font size=2 face="sans-serif"> The
substitution or exception can refer to the variable, but not knowing which
one.</font>
<br><font size=2 face="sans-serif"> Rajan: The
jumped to location should follow the standard C scoping rules so it would
only refer to one specific object.</font>
<br><font size=2 face="sans-serif"> The pragma
can refer to variables declared before or after the pragma.</font>
<br><font size=2 face="sans-serif"> Presubstitution:
"In this block, make this presubstitution." The variables can
be before or after the #pragma.</font>
<br><font size=2 face="sans-serif"> Regular
C requires it to be after the declaration to know what the variable is.</font>
<br><font size=2 face="sans-serif"> Can require
nested block after all the declarations with the pragma as the first statement.</font>
<br><font size=2 face="sans-serif"> For example
f1 and g1 are calculated already somewhere (perhaps before the pragma,
or perhaps inside since they change per iteration)</font>
<br><font size=2 face="sans-serif"> f1/g1
are substituted in place of f/g if g = 0.</font>
<br><font size=2 face="sans-serif"> It
can be done either way.</font>
<br><font size=2 face="sans-serif"> Implicit
blocking or explicit? Explicit makes it easier for the implementors and
possibly clearer for the programmer.</font>
<br><font size=2 face="sans-serif"> Consensus:
Require the #pragma right after the opening curly brace. This means the
variables it refers to must have been declared before the block immediately
containing the #pragma.</font>
<br><font size=2 face="sans-serif"> Labels:
Like goto's, one pass compilers already have to handle it so it would not
be more complicated work.</font>
<br><font size=2 face="sans-serif"> Can
treat jumping to the label it as if it was an explicit goto.</font>
<br><font size=2 face="sans-serif"> Functions
and variables have to be declared before use in C but labels do not. This
will not be new if we treat our FP labels the same as the goto labels.</font>
<br><font size=2 face="sans-serif"> Goto
type label scope is function scope. It can be referred to anywhere in the
function (even before it's implicit declaration).</font>
<br><font size=2 face="sans-serif"> Alternatives to
try/catch/pragma:</font>
<br><font size=2 face="sans-serif"> In the reflector
discussion, the goto style trap handler set a bit and the programmer tests
that bit.</font>
<br><font size=2 face="sans-serif"> It is the
same as the flags with including the sub-expressions and exact underflows
with new functions to check them.</font>
<br><font size=2 face="sans-serif"> David: This
removes the ASAP property.</font>
<br><font size=2 face="sans-serif"> Jim: Can
still do this through a pragma which breaks to the checking block upon
any exception.</font>
<br><font size=2 face="sans-serif"> David: The
save/clear/test/restore requirement is still there. Don't want to drown
the normal case.</font>
<br><font size=2 face="sans-serif"> Rajan: Wasn't
the discussion with the macro's to hide the complexity?</font>
<br><font size=2 face="sans-serif"> It won't
work that well with macros. Nested macros have problems too. Handling the
exceptions cause the issues.</font>
<br><font size=2 face="sans-serif"> Should we put this
in a committee draft form now for the mailing?</font>
<br><font size=2 face="sans-serif"> It can help,
but we may not be ready.</font>
<br><font size=2 face="sans-serif"> Concerns
about tying our hands for future changes.</font>
<br><font size=2 face="sans-serif"> Possible
better responses from WG14 as a proposal.</font>
<br><font size=2 face="sans-serif"> *ToDo: Part
5: David: Prepare a complete specification for alternate exception handling
by the end of August.</font>
<br><font size=2 face="sans-serif"> Reformat
after the September teleconference for submission to the WG14 mailing.</font>
<br><font size=2 face="sans-serif"> Should we
make the remainder (optimization, etc.) as part 6?</font>
<br><font size=2 face="sans-serif"> Better
if we don't since we have approval for 5 parts and we have listed it as
5 parts in the existing earlier parts including published ones.</font>
<br><font size=2 face="sans-serif"> We
can put in blank headed sections for the remaining parts of part 5 so all
of WG14 knows they are coming.</font>
<br><font size=2 face="sans-serif"> Subexceptions:</font>
<br><font size=2 face="sans-serif"> If no feature
test macro is there for a subexception, then it is not supported.</font>
<br><font size=2 face="sans-serif"> Fear is
making it optional means it may never be implemented.</font>
<br><font size=2 face="sans-serif"> Will part
5 be more likely to be implemented if the individual subexceptions are
optional?</font>
<br><font size=2 face="sans-serif"> It
may be easy on some hardware for some of the subexceptions so they may
just do those.</font>
<br><font size=2 face="sans-serif"> Even
if it is required, implementers may still do most of part 5 and mention
they are not conforming on aspects x, y, z.</font>
<br><font size=2 face="sans-serif"> Consensus:
Require all the subexceptions.</font>
<br><font size=2 face="sans-serif"> ASAP vs deferred:</font>
<br><font size=2 face="sans-serif"> Can allow
the implementation to choose which way.</font>
<br><font size=2 face="sans-serif"> Some times
you definitely want deferred, so you need to be able to choose.</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>