<font size=2 face="sans-serif"><b>Attendees</b>: Rajan, Jim, David, Mike,
Ian, Vincent</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>
<br><font size=2 face="sans-serif"><b>Last meeting action items</b>:</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-diff-20150211-20150309.pdf:
p9: Line 10: Note that we need to make sure functions with two or more
arguments (since the order of evaluation of them is not fixed) is handled.
- Listed as unspecified behaviour in IEEE. In our spec we say in Annex
J the program has to deal with it. *Jim to send an email regarding this.</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-diff-20150211-20150309.pdf:
p9: Line 37: Look into tightening the underflow and inexact part. - Still
open. - IEEE says the program can't depend on inexact or underflow. David:
May be due to before or after rounding. *Keep open. David: With underflow,
flags and traps are not the same due to exact underflow.</font>
<br>
<br><font size=2 face="sans-serif"> Jim: cfp5-20150330.pdf: p4: Line
20: FLT_EVAL_METHOD -> DEC_EVAL_METHOD - Done</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-20150330.pdf: p4: Line
32: actually -> actual - Done</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-20150330.pdf: p6: Line
23: Take into account rounding direction. - Already taken care of.</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-20150330.pdf: p7: line
25 is misnumbered. It appears that one of the blank lines between
20 and 25 has a number. - Done</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-20150330.pdf: p7: Line
10 is a line number on a blank line - Done</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-20150330.pdf: p7: Last
line: "NOTEIEC" appears to be missing a space. It has a tab.
- Will leave it as is to see how it looks after publish edits.</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-20150330.pdf: p7: Lines
31-32: Consider adding note about directed rounding - Seems to be taken
care of already.</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-20150330.pdf: p9: Lines
3 and 6: Consider clearer wording, maybe identifying IEEE/IEC section number
- Done</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-20150330.pdf: p10:
Line 43: NOEXCEPT: Like default, but no flag is set: wording improvement
needed. - Done</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-20150330.pdf: p11:
Line 3: OPTEXCEPT: Like default, but flag setting is optional: wording
improvement needed. - Done</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-20150330.pdf: p11:
Line 4: Reference IEEE for the meaning of 'tiny'. Also look into 'preliminary'
and exact underflow. - After the rewrite, not an issue.</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-20150330.pdf: p11:
Line 21: affect -> effect - Done</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-20150330.pdf: p11:
Line 29: Remove "undefined behaviour" statement for every action
that has a "shall" requirement already (BREAK, GOTO, DELAYED_GOTO).
- Done</font>
<br>
<br><font size=2 face="sans-serif"><b>New action items</b>:</font>
<br><font size=2 face="sans-serif"> Ian: Talk to Michael Wong and
Lowell regarding proposing this IEEE-754: 2008 binding to C++ as well.</font>
<br><font size=2 face="sans-serif"> Rajan, Jim: Talk to David Keaton
regarding our intent for putting the essentials of parts 1 and 2 (not necessarily
exact match) of this TS into the next C Standard.</font>
<br><font size=2 face="sans-serif"> Jim: Part 5: Write up the delayed
goto transformation to prolog/epilog code.</font>
<br><font size=2 face="sans-serif"> Jim: Part 5: Write up text to
allow 'break's to still cause the epilog code to be executed for delayed
goto's.</font>
<br><font size=2 face="sans-serif"> Jim: Part 5: Add in examples
of ASAP and Delayed Goto pragma's in the same block and in different orders.</font>
<br><font size=2 face="sans-serif"> Jim: Part 5: Add in a new issue
- Is it worth adding expression evaluation methods that widen the library
functions as well as the operators (that is already there)?</font>
<br><font size=2 face="sans-serif"> David: Part 5: Provide a mechanism
(a new #pragma?) to allow implementations to possibly not propagate constant
modes (rounding, exceptions).</font>
<br>
<br><font size=2 face="sans-serif"><b>Next Meeting</b>:</font>
<br><font size=2 face="sans-serif"> June 11th, 2015, 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"> Note: This is Thursday!</font>
<br>
<br><font size=2 face="sans-serif"><b>Discussion</b>:</font>
<br><font size=2 face="sans-serif"> Wiki cleanup: Older drafts need
to be cleaned up on the wiki. Anyone can volunteer for this. Ex. Making
a historical documents section. Meetings section as well. Topics page,
etc. all need updating.</font>
<br>
<br><font size=2 face="sans-serif"> WG14 meeting:</font>
<br><font size=2 face="sans-serif"> Congratulations to Jim
on the INCITS award for excellence for the work on these TS's.</font>
<br><font size=2 face="sans-serif"> IEEE binding parts 3 and
4 approved to go to publish after editorial review.</font>
<br><font size=2 face="sans-serif"> Part 5 looks good with
some issues as will be discussed as per Jim's emails.</font>
<br><font size=2 face="sans-serif"> Should we propose to put
the tech specs into the next C standard (or SD3)?</font>
<br><font size=2 face="sans-serif"> Parts 1-4 now and
5 later? 1-2 now, 3-5 later? All later? None (keep it as a tech spec)?</font>
<br><font size=2 face="sans-serif"> Jim: Better to
put it into the C11 update (after LaTeX conversion) now since it is certain
to uncover problems.</font>
<br><font size=2 face="sans-serif"> Should we have
the proposal in early or later? By the Fall meeting or after that?</font>
<br><font size=2 face="sans-serif"> Given C usually
does not take unimplemented specifications, we should do Parts 1 and 2
since part 1 is implemented by Intel and GCC, and Part 2 is implemented
by IBM. The level of conformance to the implementation is still likely
not exact, but should be close or very close.</font>
<br><font size=2 face="sans-serif"> Perhaps just state
the intent we want some/all of this into the C standard.</font>
<br><font size=2 face="sans-serif"> This should be proposed
for C++ as well. *ToDo: Ian to talk to Michael Wong and Lowell regarding
proposing this binding to C++.</font>
<br><font size=2 face="sans-serif"> *ToDo: Rajan to work with
Jim to talk to David Keaton regarding our intent for putting essentially
parts 1 and 2 (not necessarily exact match) of this TS into the next C
Standard.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Part 1: Published.</font>
<br>
<br><font size=2 face="sans-serif"> Part 2: Published. Updated to
the correct formatting and style. Cover page had an issue but that is being
fixed. Date macro fixed as well. Second edition should be published very
soon.</font>
<br>
<br><font size=2 face="sans-serif"> Part 3: Same process as part
2. Part 3 is ready for the review committee.</font>
<br>
<br><font size=2 face="sans-serif"> Part 4: Same process as part
2. Part 4 should be done by end of week and then the review committee will
be set up.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Part 5: Various emails (Fwd:
[Cfp-interest] CFP Teleconference - Tuesday, May 19, 05/18/2015 01:22 PM).</font>
<br><font size=2 face="sans-serif"> Issue 1: The IEEE spec
seems to say (a) - handle the exception using default exception handling.
The implementation can be with a transform to a prolog/epilog using flags
as stated in the IEEE spec. That can answer these questions. See David's
note for the expected transformation in psuedo-code.</font>
<br><font size=2 face="sans-serif"> For multiple goto's,
the second delayed goto's pragma results in an inner prolog/epilog outside
the first delayed goto's pragma's prolog/epilog so it will be handled first.</font>
<br><font size=2 face="sans-serif"> We should have
the transformation listed as the equivalent effect in the text.</font>
<br><font size=2 face="sans-serif"> *ToDo: Jim: Write
up the transformation as the delayed goto mechanism.</font>
<br><font size=2 face="sans-serif"> Issue 2: Apply the transformation
and so the goto/function would be taken directly. Perhaps say the effect
happens if we actually fall out from the bottom of the associated block.</font>
<br><font size=2 face="sans-serif"> Break's should
be a normal exit from the block?</font>
<br><font size=2 face="sans-serif"> *ToDo: Jim: Write
up text to allow break's to still cause the epilog code to be executed
for delayed goto's.</font>
<br><font size=2 face="sans-serif"> Issue 3: Any inner/later
#pragma would take precedence as to exception handling as per the transformation
to prolog/epilog. Note if ASAP goto is first, then delayed goto, ASAP still
occurs since it is before the end of the block. *ToDo: Jim: Create some
examples of these cases.</font>
<br><font size=2 face="sans-serif"> Issue 4: Try Catch + pragma
syntax:</font>
<br><font size=2 face="sans-serif"> David: Having try
before catch is nice.</font>
<br><font size=2 face="sans-serif"> Should we even
have try/catch?</font>
<br><font size=2 face="sans-serif"> If so, should the
try/catch be in the same curly brace set?</font>
<br><font size=2 face="sans-serif"> Should the curly
brace come before or after the pragma?</font>
<br><font size=2 face="sans-serif"> Don't put it in
due to matching try/catch blocks and exception lists, and dealing with
scope, etc. issues</font>
<br><font size=2 face="sans-serif"> We can list this
as an idea considered and rejected when part #5 is presented.</font>
<br><font size=2 face="sans-serif"> Issue 5: Similar to constant
rounding direction modes.</font>
<br><font size=2 face="sans-serif"> Consensus: Yes,
keep similar to constant rounding modes.</font>
<br><font size=2 face="sans-serif"> Sequence point
rules seem to not require explicit calling out of argument conversion before
the call.</font>
<br><font size=2 face="sans-serif"> *New Issue: Is
it worth adding expression evaluation methods that widen the library functions
as well as the operators (that is already there)?</font>
<br><font size=2 face="sans-serif"> Before you
could use the _t declarations (ex. float_t) and use type generics to get
the same effect as widening.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Should we have a way of
having constant rounding or other modes apply to user functions as well?</font>
<br><font size=2 face="sans-serif"> *ToDo: David: Provide
a mechanism (a new #pragma?) to allow implementations to possibly not propagate
constant modes (rounding, 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: rbhakta@us.ibm.com, Rajan Bhakta/Houston/IBM</font>