<font size=2 face="sans-serif"><b>Attendees</b>: Rajan, Jim, Vincent,
David, Fred, 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"> Discussion of WG14 meeting.</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"> David: Send out an email
address to sign yourself up to the IEEE-754 mailing list to this group.
- 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 1
features in other languages. - Keep open. Will discuss later (about 30-40
languages use Mike's package at the moment).</font><br><font size=2 face="sans-serif"> Jim: p5: Give example
of what the TG math functions effect due to the macro would do and what
would happen without it. - Done.</font><br><font size=2 face="sans-serif"> Jim: p12: See if we can
add a footnote regarding the implementation defined/unspecified/undefined
behavior referring to Annex J and/or an example from one of the bullets
ommitted. - Done in an alternative form.</font><br><font size=2 face="sans-serif"> Jim: p8: Make subnormal
zero case be something that should keep the same sign. - Not done. After
discussion, seemed better to not do this due to performance reasons.</font><br><font size=2 face="sans-serif"> Jim: p15: line 31: ilogb
-> ilogb and llogb. - Done.</font><br><font size=2 face="sans-serif"> Jim: p15: line 32: FE_INVALID_LOGB
-> FE_INVALID_ILOGB. - Done.</font><br><font size=2 face="sans-serif"> Jim: p16: line 10: Remove
'and round result to narrower type'. - Done.</font><br><font size=2 face="sans-serif"> Jim: p9: FENV_ALLOW_CONTRACT_FMA:
Send a note to convey this should not apply to any implementation/system
operations, and only to user code that is directly what is listed in lines
11-14. - Done on p6.</font><br><br><font size=2 face="sans-serif"><b>New action items</b>:</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.</font><br><font size=2 face="sans-serif"> Jim: p18: Line 3: a catch
action -> catch actions (look into making the change)</font><br><font size=2 face="sans-serif"> Jim: p18: Line 34: a delayed-catch
action -> delayed-catch actions (look into making the change)</font><br><font size=2 face="sans-serif"> Jim: p18: Line 21: without
the break -> without the jump</font><br><font size=2 face="sans-serif"> Jim: p21: Line 41: Reference
the section this footnote is in.</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).</font><br><font size=2 face="sans-serif"> Rajan: Present part 5
to WG14.</font><br><font size=2 face="sans-serif"> Rajan: Put up a PDF of
the feature lists.</font><br><font size=2 face="sans-serif"> David: See what Oracle
has done for the feature lists.</font><br><font size=2 face="sans-serif"> Rajan, Fred: See if there
is a time pressure for new C Standard proposals.</font><br><font size=2 face="sans-serif"> Rajan, Fred: Report on
the WG14 meeting with respect to the TS's.</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.</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><br><font size=2 face="sans-serif"><b>Next Meeting</b>:</font><br><font size=2 face="sans-serif"> November 10th, 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: David: Going
forward. Mike is editor.</font><br><br><font size=2 face="sans-serif"> Arith23: Marius: No reply
yet from program/steering committee members from what we discussed last
time. Marius will ping them.</font><br><br><font size=2 face="sans-serif"> Parts 3 and 4: Published
on October 1st, 2015. They are on the ISO website.</font><br><br><font size=2 face="sans-serif"> Part 5: Various emails,
documents (cfp5-20151007.pdf)</font><br><font size=2 face="sans-serif"> pvii: Comment received
that more background information would be useful.</font><br><font size=2 face="sans-serif"> p3: Line 24: *NEW
ISSUE: Is this a constraint violation if it occurs? If so, it cannot be
diagnosable by a translator following the translation phases exactly.</font><br><font size=2 face="sans-serif"> p17: *NEW ISSUE:
For library state: Unspecified vs indeterminate state. Should not have
the standard library states be indeterminate, but can we guarentee that
it is in a valid state?</font><br><font size=2 face="sans-serif"> p18: Line 9: We
should give an example or two. Should we say we are trying to avoid the
following "bad" cases? Adding an example here would imply we
should do it for all the try/catch items here. Perhaps put it in a footnote?
May not be that helpful in a TS.</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.</font><br><font size=2 face="sans-serif"> p18: Line 15: Now
try and catch have to match exactly instead of allowing catch with sub-exceptions
of the general group try exception. Perhaps have a new term for matching
try/catch to avoid the repeated clauses.</font><br><font size=2 face="sans-serif"> *Jim: p18: Line
3: a catch action -> catch actions (look into making the change)</font><br><font size=2 face="sans-serif"> *Jim: p18: Line
34: a delayed-catch action -> delayed-catch actions (look into making
the change)</font><br><font size=2 face="sans-serif"> *Jim: p18: Line
21: without the break -> without the jump</font><br><font size=2 face="sans-serif"> p18:</font><br><font size=2 face="sans-serif"> The changes
for jumping into/out of catch block apply to 'delayed-try' as well, and
for 'try' with the exception of handling "exceptions as specified
below".</font><br><font size=2 face="sans-serif"> The 'delayed-try/catch'
have all the corresponding changes from 'try/catch' sections.</font><br><font size=2 face="sans-serif"> Should jumping
into a compound statement be different from jumping to a compound statement
(as stated at the beginning of the paragraph)? i.e. Remove the 'other'
on line 27? The preceding statement seems to make it clear what 'other'
refers to. Consensus is there is no confusion here.</font><br><font size=2 face="sans-serif"> p21: To make the
changes valid with respect to the atomics example.</font><br><font size=2 face="sans-serif"> *Jim: p21:
Line 41: Reference the section this footnote is in.</font><br><br><font size=2 face="sans-serif"> Pursue the new
issues via email.</font><br><br><font size=2 face="sans-serif"> WG14 meeting:</font><br><font size=2 face="sans-serif"> Enough significant
changes to have this draft considered by WG14. Put it on the wiki. This
means follow up emails by noon tomorrow at the latest. This allows EOD
tomorrow to have the changes sent out.</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).</font><br><font size=2 face="sans-serif"> *Rajan: Present
part 5 to WG14.</font><br><br><font size=2 face="sans-serif"> Features list part 2:</font><br><font size=2 face="sans-serif"> Decimal operation
binding: Mike's library has all the functions in the TS, and beyond what's
in the TR.</font><br><font size=2 face="sans-serif"> Are they
in Linux already? Or any open source?</font><br><font size=2 face="sans-serif"> Fred: Conversions:
GCC does not do this correct in terms of rounding for DFP <-> BFP.
For float to integer, flags are not set properly.</font><br><font size=2 face="sans-serif"> Rounding: Mike
may know of prior art with regards to the #pragma (likely using the dynamic
rounding modes).</font><br><font size=2 face="sans-serif"> *Rajan: Put up
a PDF of the feature lists.</font><br><font size=2 face="sans-serif"> *David: See what
Oracle has done for the feature lists.</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>