<font size=2 face="sans-serif"><b>Attendees</b>: Rajan, Jim, Fred, David,
Mike, Marius, 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><br><font size=2 face="sans-serif"><b>Last meeting action items</b>:</font><br><font size=2 face="sans-serif"> Ian: Talk to Lawrence
Crawl regarding proposing this IEEE-754: 2008 binding to C++ as well. -
Not done.</font><br><font size=2 face="sans-serif"> Ian: Update and check
the items listed and flagged under Feature_List_Part_1. - Not done.</font><br><font size=2 face="sans-serif"> Jim: Send Mike an email
regarding what is needed regarding prior art/implementation for Part 2
features in other languages. - Done.</font><br><font size=2 face="sans-serif"> Jim: p18: Line 9: Put
in a footnote showing the practical effect of the selection statement restriction.
- Done.</font><br><font size=2 face="sans-serif"> Jim: p18: Line 3: a catch
action -> catch actions (look into making the change) - Done, but not
in the review draft.</font><br><font size=2 face="sans-serif"> Jim: p18: Line 34: a delayed-catch
action -> delayed-catch actions (look into making the change) - Done.</font><br><font size=2 face="sans-serif"> Jim: p18: Line 21: without
the break -> without the jump - Done.</font><br><font size=2 face="sans-serif"> Jim: p21: Line 41: Reference
the section this footnote is in. - Done.</font><br><font size=2 face="sans-serif"> Jim: Contact David Keaton
to see if he has any objection to use this new latest part 5 document for
the WG14 meeting since we have addressed all the comments (Joseph's). -
Done.</font><br><font size=2 face="sans-serif"> Rajan: Present part 5
to WG14. - Done.</font><br><font size=2 face="sans-serif"> Rajan: Put up PDF's of
the feature lists. - Done.</font><br><font size=2 face="sans-serif"> David: See what Oracle
has done for the feature lists. - Not done.</font><br><font size=2 face="sans-serif"> Rajan, Fred: See if there
is a time pressure for new C Standard proposals. - Done (none).</font><br><font size=2 face="sans-serif"> Rajan, Fred: Report on
the WG14 meeting with respect to the TS's. - Done.</font><br><font size=2 face="sans-serif"> All: Consider new issues:</font><br><font size=2 face="sans-serif"> p3: Line 24: Is
this a constraint violation if it occurs? If so, it cannot be diagnosable
by a translator following the translation phases exactly. - Not in constraint
section so doesn't need to be diagnosed.</font><br><font size=2 face="sans-serif"> p17: For library
state: Unspecified vs indeterminate state. Should not have the standard
library states be indeterminate, but can we guarantee that it is in a valid
state?</font><br><font size=2 face="sans-serif"> - Leave
as unspecified. Can't see a reasonable way to implement otherwise.</font><br><font size=2 face="sans-serif"> Should we
have a note regarding suggestion to not have stateful operations inside
an ASAP block? No.</font><br><br><font size=2 face="sans-serif"><b>New action items</b>:</font><br><font size=2 face="sans-serif"> Rajan: Get Mike in contact
with Jens to get access to the C Standard source in the GIT repository.</font><br><font size=2 face="sans-serif"> Jim: p13: line 22: Add
in a statement describing the remaining bullets to show they are not a
complete list.</font><br><font size=2 face="sans-serif"> Jim: p17: line 27: List
the actions in place of "below" or say "the remaining actions
in this sub-clause".</font><br><font size=2 face="sans-serif"> All: Consider mixed nested
try and delayed try blocks and look for cases not covered by the specification.</font><br><font size=2 face="sans-serif"> All: Focused Review of
part 5 once the updated draft comes out.</font><br><br><font size=2 face="sans-serif"><b>Next Meeting</b>:</font><br><font size=2 face="sans-serif"> December 8th, 2015, 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>Discussion</b>:</font><br><font size=2 face="sans-serif"> IEEE 754 revision:</font><br><font size=2 face="sans-serif"> No major issues
so far.</font><br><font size=2 face="sans-serif"> Some discussion
on the specification of the math functions.</font><br><font size=2 face="sans-serif"> Need to
keep an eye on this in case it impacts us.</font><br><br><font size=2 face="sans-serif"> Arith23:</font><br><font size=2 face="sans-serif"> Special session
request from Marius was accepted.</font><br><font size=2 face="sans-serif"> 3 part panel:
Half hour review of our TS's. One part from industry presenting the state
of the art support for IEEE 754 (variable length time). Final part for
the update on the 754 update revision (1h).</font><br><font size=2 face="sans-serif"> Date: June 10th-13th,
2016</font><br><font size=2 face="sans-serif"> Location: Bay area:
Santa Clara.</font><br><br><font size=2 face="sans-serif"> WG14 meeting:</font><br><font size=2 face="sans-serif"> #pragma try/catch/delayed
outside the { to allow macro replacement of #if 0 for implementations that
do not support this.</font><br><font size=2 face="sans-serif"> Also wanted a 1-1
correspondence between delayed/try and delayed/catch.</font><br><font size=2 face="sans-serif"> Mike is interested
in looking at convert the C standard from TROFF to something else.</font><br><font size=2 face="sans-serif"> *Rajan: Get Mike
in contact with Jens to get access to the C Standard source in the GIT
repository.</font><br><font size=2 face="sans-serif"> Mike: ODT is probably
better to convert to since it is XML. Being used for 754 right now.</font><br><font size=2 face="sans-serif">
</font><br><font size=2 face="sans-serif"> Part 5: Various emails,
documents (cfp5-20151104.pdf)</font><br><font size=2 face="sans-serif"> Major WG14 requests:
Move control flow pragma's outside the blocks, and have the try list match
catch's.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> p13: The second
bullet pretty much covers everything. The other thing is extensions.</font><br><font size=2 face="sans-serif"> Should we
say "the code that is written will give the same results in all implementations"?</font><br><font size=2 face="sans-serif"> Jim:
That is what this is supposed to say.</font><br><font size=2 face="sans-serif"> Defining
what reproducible means is probably sufficient. No need to give programming
notes to show how to do that.</font><br><font size=2 face="sans-serif"> Perhaps
restrict this to floating point numerical reproducibility?</font><br><font size=2 face="sans-serif"> Jim:
Branches and everything else are not floating point and restricting it
otherwise is not very useful.</font><br><font size=2 face="sans-serif"> Note
that random number generators, I/O status, etc. all affect reproducibility
as well.</font><br><font size=2 face="sans-serif"> Should the
header in line 13 be "Reproducible code sequences"?</font><br><font size=2 face="sans-serif"> Maybe.
Will affect what is listed above.</font><br><font size=2 face="sans-serif"> The first
bullet says it is for the bound floating point operations.</font><br><font size=2 face="sans-serif"> The rest
of the bullets lists things that might not be obvious or need emphasis.
It is not intended to be a complete/exhaustive list.</font><br><font size=2 face="sans-serif"> Perhaps
have something after the first two bullets to show the rest are not complete.</font><br><font size=2 face="sans-serif"> Ex.
Saying "For example the following would be required:"</font><br><font size=2 face="sans-serif"> *Jim: p13:
line 22: Add in a statement describing the remaining bullets to show they
are not a complete list.</font><br><font size=2 face="sans-serif"> p17: Describe the
two kinds of pragmas: {delayed}try/catch and break.</font><br><font size=2 face="sans-serif"> Handles
the pragma outside the block WG14 request.</font><br><font size=2 face="sans-serif"> What does
"below" mean in "actions specified below"? How big
is the "below"? Perhaps list the actions?</font><br><font size=2 face="sans-serif"> *Jim: p17:
line 27: List the actions in place of "below" or say "the
remaining actions in this sub-clause".</font><br><font size=2 face="sans-serif"> p18: Handles the
WG14 1-1 correspondence between try/catch request.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Another WG14 question
was can you mix/match delayed and non-delayed try/catch?</font><br><font size=2 face="sans-serif"> Current
spec doesn't allow a try and a delayed try in the same scope without the
catch and delayed catch blocks in between.</font><br><font size=2 face="sans-serif"> For nested,
try with a nested delayed try if the same exception occurs in the nested
block, the delayed catch handles it due to the rule about same exception
delayed try taking over.</font><br><font size=2 face="sans-serif"> If
the exception happens during the try block before the delayed try, the
jump can still happen any time even in the delayed try block. But since
you are changing the environment, it may be handled already by that rule.</font><br><font size=2 face="sans-serif"> Similarly
for try inside delayed try.</font><br><font size=2 face="sans-serif"> *All: Consider
mixed nested try and delayed try blocks and look for cases not covered
by the specification.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> p19-20: Is it useful
to have the nearly identical code sequences for try and delayed try?</font><br><font size=2 face="sans-serif"> Yes, having
something concrete helps.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Another WG14 comment:
No global floating point exception handler.</font><br><font size=2 face="sans-serif"> Default
exception handling is the 'global' handler.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Are we ready for
a focused review?</font><br><font size=2 face="sans-serif"> No major
unresolved issues left so yes.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Evaluation
format (7): Marius</font><br><font size=2 face="sans-serif"> Optimization
controls (8): David</font><br><font size=2 face="sans-serif"> Reproducibility
(9): Rajan</font><br><font size=2 face="sans-serif"> Alternate
exception handling (10): Fred</font><br><font size=2 face="sans-serif"> Rest of
the parts (intro), etc.: Ian</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Start after
the next draft is out.</font><br><font size=2 face="sans-serif"> Can be done
via email. Finish up in January meeting.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Implementation status:</font><br><font size=2 face="sans-serif"> Mike's web page
shows a number of 754 decimal implementations. He also has a decnum package
that supports everything except the encode/decode functions.</font><br><font size=2 face="sans-serif"> Intel and
HP has an implementation for all that as well.</font><br><font size=2 face="sans-serif"> Should we propose
to have parts 1-2 be included into the C standard?</font><br><font size=2 face="sans-serif"> The C1X
charter lists the prior art requirement. The other parts probably don't
have the prior art.</font><br><font size=2 face="sans-serif"> Some parts
of part 4 do have prior art so those parts could maybe be proposed.</font><br><font size=2 face="sans-serif"> The optimization
controls in part 5 have prior art too (with different syntax/methods).</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>