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