<font size=2 face="sans-serif">Hi,</font><br><br><font size=2 face="sans-serif">Sorry, I had a typo on a name. I was
in a rush to get it the mailing out due to other meetings and have corrected
it below.</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><font size=1 color=#800080 face="sans-serif">----- Forwarded by Rajan
Bhakta/Houston/IBM on 05/24/2016 03:01 PM -----</font><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</font><br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">dmk@dmk.com</font><br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">05/24/2016 01:16 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 2016/05/24</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, Fred,
Marius, David Hough, Mike, David Keaton, Ian</font><font size=3><br></font><font size=2 face="sans-serif"><b><br>New agenda items</b>:<br> Conversion of DFP to character strings.</font><font size=3><br></font><font size=2 face="sans-serif"><b><br>Last meeting action items</b>:<br> Ian: Talk to Lawrence Crowl regarding proposing this IEEE-754:
2008 binding to C++ as well. - In process. - Remove from list and make
it a discussion topic.<br> Lawrence said C changes will get incorporated into
the C++ standard by reference.<br> Not applicable in this case.<br> Ian: Update and check the items listed and flagged under
Feature_List_Part_1. - Not done. - Remove from list.<br> Jim: Post updated versions (post publication) of TS parts
on the wiki with DR resolutions. - Done.<br> Mike: Monitor the Part 5 DTS ballot to determine whether
or not to put it in the IEEE-754 revision bibliography. - In progress.<br> Once it passes, this group should notify Mike to make
the update to the IEEE-754 draft permanent.<br> Jim: Get a backup of the CFP wiki. - Done.<br> On Jim's home system and home backup.<br> EDG creates an offsite backup every 4 hours.<br> Usually gives plenty of notice if they will
not support a wiki in the future.<br> Mike: Can we get access to the backup and test
it?<br> *ToDo: Jim: Check with EDG for testing the
offsite backup.<br> Fred: Contact David Keaton and Keld to see what we can do
about getting hosting for our wiki and backups for it.<br> WG14 wiki is still down. Unknown when it will be fixed.<br> David: Still have the non-wiki functional directory
if needed.<br> Rajan: Follow up with David (cc Jim) to see how long this
TS can live and whether or not it needs to be withdrawn or made into an
IS after some period of time. - Done.<br> - David said no, does not need to be withdrawn and
can be stabilized (no need to vote to renew).<br> Jim: Invite David Keaton to help with the new C revision
discussion. - Done.</font><font size=3><br></font><font size=2 face="sans-serif"><b><br>New action items</b>:<br> Jim: Check with EDG for testing the offsite backup.<br> <b><br>Next Meeting</b>:<br> June 28th, 2016, 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> David Keaton, WG14 convener, joining today.<br> <br> IEEE 754 revision:<br> David Huff: Moving forward to completion.<br> A meta-question on whether to do anything with 2add
or not.<br> Should be done before the end of the calendar year.<br> <br> Arith23:<br> Going forward. Abstract will be able to be reviewed
before publishing.<br> Registration is open for anyone who wants to come.<br> <br> Parts 1-5:<br> DR's for parts 1-3 are in process.<br> Drafts with changes from the DR's are on the
wiki.<br> No DR's against part 4.<br> DTS for Part 5, closes in June. USA and Canada have
already begun balloting, no comments expected.<br> <br> Document conversion for the C Standard: When would
it be practical for us to make the changes to it?<br> David K: In progress, though likely to take
a while. Expecting to publish it by end of 2017 so we should have the source
much earlier than that.<br> <br> What should be proposed for the C standard (</font><a href=http://wiki.edg.com/pub/CFP/WebHome/TS_18661_for_C_standard.pdf><font size=2 color=blue face="sans-serif"><u>http://wiki.edg.com/pub/CFP/WebHome/TS_18661_for_C_standard.pdf</u></font></a><font size=2 face="sans-serif">):<br> The new IEEE-754 revision should work with the existing
TS's with the only exception being a new function being possibly added
(2add).<br> Part 1:<br> Static rounding modes support may be the most
expensive part for the implementers. Perhaps do everything other than this?<br> Jim: IEEE thought the dynamic modes
would be prohibitively expensive in the future architectures so they made
it optional and went with static rounding modes.<br> David H: More view on what programmers
wanted rather than hardware implementation. Ex. Alternate exception handling.
And the programmer generally wants only one rounding mode for a particular
computation.<br> For debugging, allowing dynamic
changes has it's uses.<br> Ian: Some hardware is only capable of
static, some is only capable of dynamic. This complicates it.<br> Can always implement static in terms
of dynamic.<br> Part 2:<br> Should list the existing DFP TR.<br> No major cost (implementation) deltas from
the TR, and mature enough to put into the standard as is.<br> Part 3:<br> Possible DR: _Binary16 should only be required
for BFP.<br> David K: Short float paper presented in London.<br> Rajan: Does provide more than one way of doing
things for some implementations which violates one of the principles of
C of only having one way of doing things.<br> Jim: Similar to the standard integer
types though these are different types with the same formats.<br> Can use the encoding functions to go
from standard to these types and vice versa.<br> Part 4:<br> David K: The reduction functions are nice interfaces.<br> Rajan: Some minor overlap with CPLEX
reduction functions.<br> Can be an annex or an optional feature.<br> Rajan: May be better to have these parts as
separate proposals to allow possibly more acceptable parts to pass.<br> David H: There are a number of new functions
that have never been implemented before and organizations may have lost
the knowledge and people to implement it.<br> Marius: If not required to be correctly rounded,
it should not be that bad.<br> Jim: There is some experience implementing
these, and some concerns about implementing them.<br> Part 5:<br> Optimization parts can be ignored since they
only allow things not require them.<br> Reproducibility is similar.<br> If the implementation already deals with types,
1 is small as well.<br> <br> Propose individual parts as separate proposals<br> Can do part 1 and 2 together, others as separate.<br> David K: More smaller proposals usually end
up with better success rates.<br> Show the grand strategy of part 1 then
2, then parts of 3-5 allowing easily digestible pieces.<br> How should we propose these?<br> David K: Start with the cover sheet/rationale,
then the changes to the standard.<br> Rajan: Perhaps have the cover
sheet/rationale, list implementers, reference the published TS, and the
DR's.<br> Pre meeting mailing deadline is September
19th so we can have 3-4 meetings to get proposals ready.</font><font size=3><br></font><font size=2 face="sans-serif"><br> Agree to propose parts 1 and 2 with possibly dealing
with constant rounding modes.</font><font size=3><br></font><font size=2 face="sans-serif"><br> Focus on parts 3-5 next meeting.<br> <br> Perhaps list pro's & con's for ourselves.<br> <br> Conversion of DFP to character strings (Fred's 2016/05/06 email):<br> David H. has an action item to look into this from the IEEE
754 group.<br> Mike and the TR and Part 2 of the TS say that we should get
an Inf and an overflow. IEEE-754 (4.3#1, 4.3#4) says otherwise.<br> Jim: Don't see that in Part 2.<br> David H: Not the intent either.<br> Fred: Page 43: Example 3.<br> Jim: Fred is right. It uses an intermediate.<br> David H: Re IEEE: What format is the intermediate result?
The answer is that it is a number, not a format.<br> The correct answer should be 3 digit exponent with
no overflow.<br> Fred: Our TS is wrong on this point.<br> Jim: Need to look at this closer.<br> David H: IEEE-754 had it right and we didn't translate it
right in this particular case.<br> Nothing specific to decimal. Should apply to binary.<br> Discuss this via email in the meantime until the next meeting.<br> <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>