<font size=2 face="sans-serif"><b>Attendees</b>: Rajan, Jim, Fred, David,
Mike, 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"> Mike: Monitor the Part
5 DTS ballot to determine whether or not to put it in the IEEE-754 revision
bibliography. - Done.</font><br><br><font size=2 face="sans-serif"> Jim: Check one of the
files from the EDG backup for testing the off site backup. - Not done.</font><br><font size=2 face="sans-serif"> Jim: Correction of David
H's name in the minutes from last meeting. - Done.</font><br><font size=2 face="sans-serif"> Work Item: Discuss writing
up issue C email reflector message 14283 (evaluation macros) as a DR against
C11. - New action item.</font><br><font size=2 face="sans-serif"> Jim: Create a DR for Part
1 for email reflector message 14280 (return = copy/convertFormat).
- Done.</font><br><font size=2 face="sans-serif"> Fred's proposed
footnote is not in the document sent out by Jim.</font><br><font size=2 face="sans-serif"> Work Item: DR for Part
3 with words needed for email reflector message 14285 (DECIMAL_DIG). -
Done (</font><a href="http://wiki.edg.com/pub/CFP/WebHome/DRs2-20160726.pdf"><font size=2 color=blue face="sans-serif">http://wiki.edg.com/pub/CFP/WebHome/DRs2-20160726.pdf</font></a><font size=2 face="sans-serif">).</font><br><font size=2 face="sans-serif"> Work Item: DR for Part
3 with words needed for email reflector message 14282 first part. - Done
(</font><a href="http://wiki.edg.com/pub/CFP/WebHome/DRs2-20160726.pdf"><font size=2 color=blue face="sans-serif">http://wiki.edg.com/pub/CFP/WebHome/DRs2-20160726.pdf</font></a><font size=2 face="sans-serif">).</font><br><font size=2 face="sans-serif"> Work Item: DR for Part
3 with words needed for email reflector message 14282 second part (tgmath).
- Done (</font><a href="http://wiki.edg.com/pub/CFP/WebHome/DRs2-20160726.pdf"><font size=2 color=blue face="sans-serif">http://wiki.edg.com/pub/CFP/WebHome/DRs2-20160726.pdf</font></a><font size=2 face="sans-serif">).</font><br><font size=2 face="sans-serif"> Work Item: Consider changing
the specification to reflect the C11 and IEEE mechanism of conversion to
strings to see what it would look like (re Fred's DFP to character string
email) in Part 2.</font><br><font size=2 face="sans-serif"> Jim sent email
on 2016/07/20 with approaches. Follow on discussion was for examples.</font><br><br><font size=2 face="sans-serif"><b>New action items</b>:</font><br><font size=2 face="sans-serif"> Jim: Writing up issue
C email reflector message 14283 (evaluation macros) as a DR against C11.</font><br><font size=2 face="sans-serif"> Jim: Add the footnote
text as per email on 2016/07/26 to Draft DR 1 ("Is return of same
type convertFormat or copy?").</font><br><font size=2 face="sans-serif"> Jim: Part 2: Page 42:
Put (significant) in front of 'number' in "integers (s, c, q), where
n is the number of digits"</font><br><font size=2 face="sans-serif"> Rajan: Send out rules
for C2X proposals to the group.</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"> August 30th, 2016, 12:00
EDT, 9:00 PST</font><br><font size=2 face="sans-serif"> Same teleconference number.</font><br><font size=2 face="sans-serif"> Next WG14 meeting
(Pittsburgh, 2016/10/17) has a September 19th mailing deadline.</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"> Incremental progress
being made.</font><br><font size=2 face="sans-serif"> Two-sum discussion.</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"> David did a report
on the 754 revision, Jim did a presentation on the TS's (sent via email
to our group).</font><br><font size=2 face="sans-serif"> Questions of how
the alternate exception handling works with parallelism like OpenMP, etc.</font><br><font size=2 face="sans-serif"> 754 doesn't
say anything there either so it is not a C specific problem.</font><br><font size=2 face="sans-serif"> If 'short float'
gets in, perhaps add something to Annex F to have binding of short float
to _Float16.</font><br><font size=2 face="sans-serif"> nVidia, ARM, Intel,
AMD all are moving to supporting _Float16. The hardware should have support
for it.</font><br><font size=2 face="sans-serif"> Machine
learning is driving this (ex. photo analysis for facial recognition, etc.)</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> C++ liaison:</font><br><font size=2 face="sans-serif"> No report.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Part 5:</font><br><font size=2 face="sans-serif"> Publication draft
was sent to ISO. ISO adds a cover page and end page (pricing).</font><br><font size=2 face="sans-serif"> That draft
had 3 problems. They were reported back to ISO, but nothing back from them
yet.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Email comments from Joseph
Myers continued (sent on 2016/06/21 to WG14 reflector, numbers 14287-14289
and surrounding):</font><br><font size=2 face="sans-serif"> Part 5:</font><br><font size=2 face="sans-serif"> Draft DR1:
</font><br><font size=2 face="sans-serif"> Fred
asked for a footnote for convertFormat vs copy.</font><br><font size=2 face="sans-serif"> Jim
sent the words via email.</font><br><font size=2 face="sans-serif"> *Jim:
Add the footnote to Draft DR 1.</font><br><font size=2 face="sans-serif"> Draft DR2:</font><br><font size=2 face="sans-serif"> Option
1:</font><br><font size=2 face="sans-serif">
May lead to having more digits than you need.</font><br><font size=2 face="sans-serif">
It is a C DR, but only relevant to extensions to C (TS part 3). Seems strange.</font><br><font size=2 face="sans-serif">
Rajan: We can make this a change to Part 3 that changes C11 to avoid
this problem.</font><br><font size=2 face="sans-serif">
</font><br><font size=2 face="sans-serif"> Option
2:</font><br><font size=2 face="sans-serif">
Only applies to TS part 3.</font><br><font size=2 face="sans-serif">
</font><br><font size=2 face="sans-serif"> Ian:
Can do both option 1 and two.</font><br><font size=2 face="sans-serif">
May be an issue for mixed runtimes or hardware or implementations.</font><br><font size=2 face="sans-serif">
Jim: Option 2 is not a runtime determination, it is a #ifdef thing.</font><br><font size=2 face="sans-serif">
Ian: Doesn't it imply the runtime will needs to know this value. Ex. print
might need to know. For buffers, etc.</font><br><font size=2 face="sans-serif">
Separately compiled things mixing can have different rules. One CU with
the STDC WANT macro defined, another without it.</font><br><font size=2 face="sans-serif">
Jim: Option 2 makes the implementation required to deal with the largest
types.</font><br><font size=2 face="sans-serif">
Normally WANT macros expose interfaces, but in this case it changes the
interface.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Due
to the multi-translation unit issue, leaning towards option 1.</font><br><font size=2 face="sans-serif"> Ian:
Perhaps add in for option 1, "and no more than the maximum digits
for any type the implementation supports". May not be a good idea
since it limits expansion.</font><br><font size=2 face="sans-serif"> Draft DR3:</font><br><font size=2 face="sans-serif"> Note
that the final change is a change to text that lists a change to C11.</font><br><font size=2 face="sans-serif"> Though
the changes are substantive this does simplify it, as Joseph stated.</font><br><font size=2 face="sans-serif"> Like
the general approach. Look at it more since it is complicated and in a
tricky area.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Conversion of DFP to character
strings (Fred's email) continued (Jim's 2016/07/20 email regarding the
work item):</font><br><font size=2 face="sans-serif"> Trying to get IEEE
conversion functionality:</font><br><font size=2 face="sans-serif"> Options 1 and 3
are not unreasonable, but 2 has the least impact on behaviour.</font><br><font size=2 face="sans-serif"> Option 1 seems
easier from an implementation point of view, but option 3 is the easiest
from that point of view.</font><br><font size=2 face="sans-serif"> For tabular printing,
having the precision helps limit the output and can be useful.</font><br><font size=2 face="sans-serif"> General inclination
for option 2.</font><br><font size=2 face="sans-serif"> Fred: Need an example
of leading zero's.</font><br><font size=2 face="sans-serif"> Jim: n is
number of digits in the coefficient. Leading zero's don't affect it.</font><br><font size=2 face="sans-serif"> Fred: Part
2 has an example with only 6 digits on printed page 43 example 2 (_Decimal32
x = 6543.00DF -> _Decimal32 x = 06543.00DF).</font><br><font size=2 face="sans-serif"> Fred: On
page 42, n is listed as the number of digits instead of significant digits.</font><br><font size=2 face="sans-serif"> *Jim:
Part 2: Page 42: Put (significant) in front of 'number' in "integers
(s, c, q), where n is the number of digits"</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/DRs2-20160726.pdf"><font size=2 color=blue face="sans-serif">http://wiki.edg.com/pub/CFP/WebHome/DRs2-20160726.pdf</font></a><font size=2 face="sans-serif">):</font><br><font size=2 face="sans-serif"> Proposal of both
part 1 and 2 in total.</font><br><font size=2 face="sans-serif"> Propose part 4
in total.</font><br><font size=2 face="sans-serif"> Perhaps
break it into the math functions and reduction functions.</font><br><font size=2 face="sans-serif"> Propose
this as a conditionally normative annex?</font><br><font size=2 face="sans-serif"> Fred: Adding
it to the main body would be too much for implementers to do.</font><br><font size=2 face="sans-serif"> Jim: Can
be a part of the main body but still be conditional (ex. complex, atomics).</font><br><font size=2 face="sans-serif"> Can say
upfront that this can be an annex.</font><br><font size=2 face="sans-serif"> Jim: If 754 adopts
twoSum or twoProduct, it would be good to get it in.</font><br><font size=2 face="sans-serif"> For Part 5:</font><br><font size=2 face="sans-serif"> Propose
the expression control pragmas, and the optimization pragmas as separate
things.</font><br><font size=2 face="sans-serif"> For reproducible
results, can propose this only after optimization and evaluation methods
are accepted.</font><br><font size=2 face="sans-serif"> For alternate
exception handling, should we consider the OpenMP concerns as part of the
proposal?</font><br><font size=2 face="sans-serif"> Similar
issues occurred before Part 5. Ex. Implementing it with flags in C99.</font><br><font size=2 face="sans-serif"> For 'short float',
OK with making it _Float16? Yes.</font><br><font size=2 face="sans-serif"> Can C refer to
the TS?</font><br><font size=2 face="sans-serif"> Ex. Refer
to Part 3 in the main standard since Part 3 is a very large change to the
standard and keeping it separate may be more palatable.</font><br><font size=2 face="sans-serif"> Question
for David Keaton.</font><br><font size=2 face="sans-serif"> Jim: How do we
submit proposals?</font><br><font size=2 face="sans-serif"> *Rajan: Send out
rules for C2X proposals to the group.</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>