<font size=2 face="sans-serif"><b>Attendees</b>: Rajan, Jim, David H.,
Fred, Mike, David Chen</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"> 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: Writing up issue
C email reflector message 14283 (evaluation macros) as a DR against C11.
- Done (DR1 in the proposed DR's sent out).</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?"). - Done (Draft DR3).</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" - Done (no parenthesis).</font><br><font size=2 face="sans-serif"> Rajan: Send out rules
for C2X proposals to the group. - Done.</font><br><br><font size=2 face="sans-serif"><b>New action items</b>:</font><br><font size=2 face="sans-serif"> Jim: Update the proposal
for Part 2 to make it more similar to Part 1's proposal.</font><br><font size=2 face="sans-serif"> Jim: For all proposals:
Change to "This proposal incorporates" as the starting.</font><br><font size=2 face="sans-serif"> Rajan: Proposal 1: Update
the spreadsheet of part 1 features based on Marius' note and send it out
to the group for final review.</font><br><font size=2 face="sans-serif"> Rajan: Proposal 1: Change
the prior art text that has "ex." to "Example:" since
Ex. could mean excluding.</font><br><font size=2 face="sans-serif"> Rajan: Proposal 2: Add
in prior art based off the spreadsheet of features.</font><br><font size=2 face="sans-serif"> Jim: Proposal 4b: Mention
underflow as well (alongside the existing overflow).</font><br><font size=2 face="sans-serif"> Jim: Proposal 5a: Look
at leaving out the types in the second paragraph.</font><br><font size=2 face="sans-serif"> Jim: Proposal 5d: Title:
alternate expression handling -> alternate exception handling</font><br><font size=2 face="sans-serif"> Jim: Proposal 5d: Say
"portable handling of exceptional cases".</font><br><font size=2 face="sans-serif"> Jim: Proposal 5d: Simplify
the abstract by removing the detail after "Some actions control".</font><br><font size=2 face="sans-serif"> Jim: Proposal 5d: Say
"The pragma allows the program to deal with exceptional cases without
having to consider implementation details."</font><br><font size=2 face="sans-serif"> Jim: DDR7: Integrate the
changes proposed for the usual arithmetic conversions into a combined document
to make it easier to read/understand.</font><br><font size=2 face="sans-serif"> Jim: DDR?: Create a new
DDR for the typo that Joseph just raised in reflector message 14358.</font><br><font size=2 face="sans-serif"> Jim: Consult with Mike
to discuss the preferred quantum exponent for hypot (in the TS), rsqrt,
pow* (in the TS), etc.</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"> September 27th, 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"> </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"> Had a long discussion
on comparisons. Is it mandated to compare different formats but with the
same radix?</font><br><font size=2 face="sans-serif"> Ex. How
many signals do you get?</font><br><font size=2 face="sans-serif"> If the operations
are required, can anything we (WG14) have proposed detect the difference?
</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"> Ian not present.</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"> Published.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> What should be proposed
for the C standard (Jim's email sent on 2016/08/28):</font><br><font size=2 face="sans-serif"> All the parts are
proposed in the TS as optional features other than Part 1.</font><br><font size=2 face="sans-serif"> Feature
macros, want macros, etc.</font><br><font size=2 face="sans-serif"> Can add it to the
proposals.</font><br><font size=2 face="sans-serif"> May need changing
macros, etc. if proposals are merged or not.</font><br><font size=2 face="sans-serif"> We're currently
not proposing them as optional other than the parts with the WANT macros.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Part 1 + Part 2
together or separate?</font><br><font size=2 face="sans-serif"> Mike: Part
1 and 2 should have the same gravity.</font><br><font size=2 face="sans-serif"> Most of
part 1 is in Annex F which is an optional feature. We have made changes
in the main part of the standard as well (like new functions).</font><br><font size=2 face="sans-serif"> May be easier
to get part 1 approved than part 1 + 2 since part 1 is in the standard
already.</font><br><font size=2 face="sans-serif"> Mike: May
be better to have both or none rather than one and not the other.</font><br><font size=2 face="sans-serif"> These
are the required parts of 754.</font><br><font size=2 face="sans-serif"> They
should have been a single section.</font><br><font size=2 face="sans-serif"> Jim: The
issue is not matching IEEE, it is the language standard which determines
what fits for it.</font><br><font size=2 face="sans-serif"> The
second proposal does list the tie in of both parts, but perhaps we need
to sell decimal better in the proposal with perhaps references to Mike's
site.</font><br><font size=2 face="sans-serif"> Mike:
Remove the "in recognition" part since it should be part of the
IEEE binding in general instead of being apologetic. It could say the same
as part 1 that it updates C for decimal changing to 'add' instead of 'update'
where appropriate.</font><br><font size=2 face="sans-serif"> Jim:
There is no updating of decimal since it's not there in the C standard
while binary is.</font><br><font size=2 face="sans-serif"> *ToDo:
Jim: Update the proposal for Part 2 to make it more similar to Part 1's
proposal.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Prior art needs
to be specified.</font><br><font size=2 face="sans-serif"> If anything does
not get in, we can have references to the TS's themselves.</font><br><font size=2 face="sans-serif"> Ex. Extended
types don't make it in, we can reference the TS in the standard.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Part 1 proposal:</font><br><font size=2 face="sans-serif"> Mike: Minor:
"This proposal incorporates" as the starting.</font><br><font size=2 face="sans-serif"> David H:
1989 should be 1985 for IEC 60559.</font><br><font size=2 face="sans-serif"> Jim/Fred:
1989 is the correct year for it.</font><br><font size=2 face="sans-serif"> Jim: Don't
want to add in the part about signalling NaN's but since it is sizable,
had to add it.</font><br><font size=2 face="sans-serif"> *ToDo: Rajan:
Update the spreadsheet of features based on Marius' note and send it out
to the group for final review.</font><br><font size=2 face="sans-serif"> *ToDo: Rajan:
Change the prior art from Ex. to Example: since Ex. could mean excluding.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Part 2 proposal:</font><br><font size=2 face="sans-serif"> No comments
other than the expected wording changes to mirror part 1's proposal.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Part 4a proposal:</font><br><font size=2 face="sans-serif"> Fred: The
"units of pi" seemed weird since shouldn't they be degrees?</font><br><font size=2 face="sans-serif"> Jim:
No, it is for the sinpi type functions.</font><br><font size=2 face="sans-serif"> Perhaps
say "half revolutions" in parenthesis as well?</font><br><font size=2 face="sans-serif"> Leave
as is.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Should formatting
for headers, cr, etc. be changed?</font><br><font size=2 face="sans-serif"> No, plain
text is better for abstracts.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Part 4b proposal:</font><br><font size=2 face="sans-serif"> Fred: Do
the functions avoid intermediate underflow?</font><br><font size=2 face="sans-serif"> David
H: Yes they do.</font><br><font size=2 face="sans-serif"> *ToDo:
Jim: Mention underflow as well.</font><br><font size=2 face="sans-serif"> The implementation
can do the platform specific work for performance while leaving the code
(not results) portable.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Part 5a proposal:</font><br><font size=2 face="sans-serif"> Mike: Should
the "The proposed specification requires binary ..." part be
dropped since there is a lot of detail there.</font><br><font size=2 face="sans-serif"> Perhaps
simplify it?</font><br><font size=2 face="sans-serif"> *ToDo:
Jim: Proposal 5a: Look at leaving out the types in the second paragraph.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Part 5b proposal:</font><br><font size=2 face="sans-serif"> No comments.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Part 5c proposal:</font><br><font size=2 face="sans-serif"> No comments.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Part 5d proposal:</font><br><font size=2 face="sans-serif"> Say portable
handling of exceptional cases.</font><br><font size=2 face="sans-serif"> *Mike: Simplify
it by removing the detail after "Some actions control".</font><br><font size=2 face="sans-serif"> David H:
The intention is to allow the programmer to look at the highest possible
level instead of being concerned with implementation details.</font><br><font size=2 face="sans-serif"> David H:
The pragma allows the program to deal with exceptional cases without having
to consider implementation details.</font><br><font size=2 face="sans-serif"> David H:
The prior art final sentence, should we say what we chose and why?</font><br><font size=2 face="sans-serif"> Jim:
That might be a statement for all the proposals (Example: rounding direction)
since that is the prior art in C for things.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> David H: Should
we have an overall introduction?</font><br><font size=2 face="sans-serif"> Jim: It
was our goal to minimize the invention. Perhaps say that for the cover
letter?</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Email comments from Joseph
Myers continued (</font><a href="http://wiki.edg.com/pub/CFP/WebHome/DRs2-20160822.pdf"><font size=2 color=blue face="sans-serif">http://wiki.edg.com/pub/CFP/WebHome/DRs2-20160822.pdf</font></a><font size=2 face="sans-serif">):</font><br><font size=2 face="sans-serif"> DDR1: (C)</font><br><font size=2 face="sans-serif"> It could
have been read to apply to unary operators (widening them) which was not
the intent.</font><br><font size=2 face="sans-serif"> Fred: Note
that at some point WG14 will stop accepting DR's and then it would have
to be a proposal.</font><br><font size=2 face="sans-serif"> Rajan: I
thought they only close off DR's for standards that already have newer
versions and just have a cut-off where all closed DR's make it in to the
next draft of the standard while others don't.</font><br><font size=2 face="sans-serif"> Subject
to email discussion before this meeting to add in "In all cases, assignment
and cast remove all extra range and precision."</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> DDR2: (C) DECIMAL_DIG</font><br><font size=2 face="sans-serif"> No comments:</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> DDR3:</font><br><font size=2 face="sans-serif"> No comments.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> DDR4:</font><br><font size=2 face="sans-serif"> No comments.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> DDR5:</font><br><font size=2 face="sans-serif"> No comments.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> DDR6:</font><br><font size=2 face="sans-serif"> Removed
the parenthesis from Fred's suggestion.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> DDR7:</font><br><font size=2 face="sans-serif"> Fred: Does
this cover _Float32x being greater width than long double in the usual
arithmetic conversions?</font><br><font size=2 face="sans-serif"> Jim:
This only applies to when the formats are the same.</font><br><font size=2 face="sans-serif"> *Jim: Can
integrate it for the usual arithmetic conversions to make it easier to
read/understand.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> We should add that
typo that Joseph just raised this morning.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Other:</font><br><font size=2 face="sans-serif"> Jim: Currently
we have preferred quantum exponents for some of the math functions but
not all (Example: The math functions in part 4). We should add it for them
as well to be in sync with the new revision of 754.</font><br><font size=2 face="sans-serif"> David H: Doesn't
happen that often, but for some functions like hypot it can. Mike is the
expert but doesn't care so...</font><br><font size=2 face="sans-serif"> If 754 does
add it then C should as well. Otherwise don't.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Jim: twoSum/twoProd:
If they go in we can try to get them in for C2X as well if the math functions
proposal get in, or into the TS if they don't.</font><br><font size=2 face="sans-serif"> They have
two inputs and two outputs.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Jim: 'a/A' style
formatting for decimal:</font><br><font size=2 face="sans-serif"> If the precision
is shorter than required for the input then the conversion is not a true
IEEE conversion due to the overflow case not being handled according to
IEEE.</font><br><font size=2 face="sans-serif"> Through
email, we favored the second option. Wording is in the 2016/08/29 email
from Jim.</font><br><font size=2 face="sans-serif"> Perhaps
we should keep the type and round to the precision and range of that type.</font><br><font size=2 face="sans-serif"> This
would be closer to what is already specified, otherwise we don't really
know the effects of the change.</font><br><font size=2 face="sans-serif"> Jim
to send out something if he can come up with something.</font><br><font size=2 face="sans-serif"> Fred: Can
say rounding with unbounded exponent (assuming just taking the words as
is and tweaking).</font><br><font size=2 face="sans-serif"> Jim:
Once you do that the rest of the spec says it is treated as if the precision
is not specified but this doesn't apply since there is no typed format
for the result.</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>