<font size=2 face="sans-serif">As per my action item: The pdf versions
of the features list files are on the wiki now.</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><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Rajan Bhakta/Houston/IBM@IBMUS</font><br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"cfp-interest@oakapple.net"
<cfp-interest@oakapple.net></font><br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">10/13/2015 12:55 PM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">[Cfp-interest]
WG14 IEEE 754-C binding meeting minutes 2015/10/13</font><br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">cfp-interest-bounces@oakapple.net</font><br><hr noshade><br><br><br><font size=2 face="sans-serif"><b>Attendees</b>: Rajan, Jim, Vincent,
David, Fred, Mike, Marius, Ian</font><font size=3><br></font><font size=2 face="sans-serif"><b><br>New agenda items</b>:<br> Discussion of WG14 meeting.</font><font size=3><br></font><font size=2 face="sans-serif"><b><br>Last meeting action items</b>:<br> Ian: Talk to Lawrence Crawl regarding proposing this IEEE-754:
2008 binding to C++ as well. - Not done.<br> David: Send out an email address to sign yourself up to the
IEEE-754 mailing list to this group. - Done.<br> Ian: Update and check the items listed and flagged under
Feature_List_Part_1. - Not done.<br> 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).<br> Jim: p5: Give example of what the TG math functions effect
due to the macro would do and what would happen without it. - Done.<br> 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.<br> 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.<br> Jim: p15: line 31: ilogb -> ilogb and llogb. - Done.<br> Jim: p15: line 32: FE_INVALID_LOGB -> FE_INVALID_ILOGB.
- Done.<br> Jim: p16: line 10: Remove 'and round result to narrower type'.
- Done.<br> 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><font size=3><br></font><font size=2 face="sans-serif"><b><br>New action items</b>:<br> Jim: p18: Line 9: Put in a footnote showing the practical
effect of the selection statement restriction.<br> Jim: p18: Line 3: a catch action -> catch actions (look
into making the change)<br> Jim: p18: Line 34: a delayed-catch action -> delayed-catch
actions (look into making the change)<br> Jim: p18: Line 21: without the break -> without the jump<br> Jim: p21: Line 41: Reference the section this footnote is
in.<br> 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).<br> Rajan: Present part 5 to WG14.<br> Rajan: Put up a PDF of the feature lists.<br> David: See what Oracle has done for the feature lists.<br> Rajan, Fred: See if there is a time pressure for new C Standard
proposals.<br> Rajan, Fred: Report on the WG14 meeting with respect to the
TS's.<br> All: Consider new issues:<br> 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.<br> 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><font size=3><br></font><font size=2 face="sans-serif"><b><br>Next Meeting</b>:<br> November 10th, 2015, 12:00 EST, 9:00 PDT<br> Same teleconference number.</font><font size=3><br></font><font size=2 face="sans-serif"><b><br>Discussion</b>:<br> IEEE 754: David: Going forward. Mike is editor.</font><font size=3><br></font><font size=2 face="sans-serif"><br> Arith23: Marius: No reply yet from program/steering committee
members from what we discussed last time. Marius will ping them.</font><font size=3><br></font><font size=2 face="sans-serif"><br> Parts 3 and 4: Published on October 1st, 2015. They are on
the ISO website.</font><font size=3><br></font><font size=2 face="sans-serif"><br> Part 5: Various emails, documents (cfp5-20151007.pdf)<br> pvii: Comment received that more background information
would be useful.<br> 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.<br> 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?<br> 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.<br> *Jim: p18: Line 9: Put in a footnote showing the practical
effect of the selection statement restriction.<br> 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.<br> *Jim: p18: Line 3: a catch action -> catch actions
(look into making the change)<br> *Jim: p18: Line 34: a delayed-catch action -> delayed-catch
actions (look into making the change)<br> *Jim: p18: Line 21: without the break -> without
the jump<br> p18:<br> 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".<br> The 'delayed-try/catch' have all the corresponding
changes from 'try/catch' sections.<br> 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.<br> p21: To make the changes valid with respect to the
atomics example.<br> *Jim: p21: Line 41: Reference the section this
footnote is in.</font><font size=3><br></font><font size=2 face="sans-serif"><br> Pursue the new issues via email.</font><font size=3><br></font><font size=2 face="sans-serif"><br> WG14 meeting:<br> 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.<br> *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).<br> *Rajan: Present part 5 to WG14.</font><font size=3><br></font><font size=2 face="sans-serif"><br> Features list part 2:<br> Decimal operation binding: Mike's library has all
the functions in the TS, and beyond what's in the TR.<br> Are they in Linux already? Or any open source?<br> Fred: Conversions: GCC does not do this correct in
terms of rounding for DFP <-> BFP. For float to integer, flags are
not set properly.<br> Rounding: Mike may know of prior art with regards
to the #pragma (likely using the dynamic rounding modes).<br> *Rajan: Put up a PDF of the feature lists.<br> *David: See what Oracle has done for the feature lists.</font><font size=3><br></font><font size=2 face="sans-serif"><br>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><tt><font size=2>_______________________________________________<br>Cfp-interest mailing list<br>Cfp-interest@oakapple.net<br></font></tt><a href="http://mailman.oakapple.net/mailman/listinfo/cfp-interest"><tt><font size=2>http://mailman.oakapple.net/mailman/listinfo/cfp-interest</font></tt></a><tt><font size=2><br></font></tt><br><BR>