<font size=2 face="sans-serif"><b>Attendees</b>: Rajan, Jim, Fred, Ian,
Mike, David</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 (Fred's 2016/05/06 email) continued.</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><font size=2 face="sans-serif"> Passed ballot.
Mike will remove the parenthetical that Part 5 is subject to change.</font><br><font size=2 face="sans-serif"> Jim: Check with EDG for
testing the off-site backup. - 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 one of the
files from the EDG backup for testing the off site backup.</font><br><font size=2 face="sans-serif"> Jim: Correction of David
H's name in the minutes from last meeting.</font><br><font size=2 face="sans-serif"> Work Item: Discuss writing
up this issue (email reflector message 14283) as a DR against C11.</font><br><font size=2 face="sans-serif"> Jim: Create a DR for Part
1 for email reflector message 14280.</font><br><font size=2 face="sans-serif"> Work Item: DR for Part
3 with words needed for email reflector message 14285.</font><br><font size=2 face="sans-serif"> Work Item: DR for Part
3 with words needed for email reflector message 14282 first part.</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).</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"> </font><br><font size=2 face="sans-serif"><b>Next Meeting</b>:</font><br><font size=2 face="sans-serif"> July 26th, 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"> IEEE 754 revision:</font><br><font size=2 face="sans-serif"> If nothing is done
with twoSum/twoAdd/tailAdd (like IBM's double-double), it'll likely be
done in the next couple meetings.</font><br><font size=2 face="sans-serif"> One of the
rationale for twoSum is the double format, there is implication for language
standards (as a type?).</font><br><font size=2 face="sans-serif"> Expected
to have quad instead of double-double for language standards.</font><br><font size=2 face="sans-serif"> In person meeting
after Arith23.</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"> Jim and David presenting
a summary overview of the TS.</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"> Nothing new. Will
start soon.</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"> Passed DTS ballot.</font><br><font size=2 face="sans-serif"> Expected to get
the publication draft to David Keaton by end of week.</font><br><font size=2 face="sans-serif"> Should be quick
turnaround for publish due to only having the date value in macros (us)
and cover page to change (ISO).</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Email comments from Joseph
Myers (sent on 2016/06/21 to WG14 reflector, numbers 14287-14289 and surrounding):</font><br><font size=2 face="sans-serif"> 14278: Jim: Re
Ian's response. Would a sNaN signal?</font><br><font size=2 face="sans-serif"> Ian: Moving
to a register doesn't signal, but may for other things.</font><br><font size=2 face="sans-serif"> Jim: Shouldn't
change the type. For the old IEEE standard, the gate C uses was just changing
the sign, not anything else.</font><br><font size=2 face="sans-serif"> Fred: Pseudo-*
(normals, etc.) may have issues. Can only get them with bit twiddling.</font><br><font size=2 face="sans-serif"> Not
part of the standard.</font><br><font size=2 face="sans-serif"> We
should mention assignment and cast and unary operators and the reason for
this in the footnote.</font><br><font size=2 face="sans-serif"> Jim:
This is widening an assignment or cast.</font><br><font size=2 face="sans-serif"> Some
implementers have not removed the extra range and precision even with a
cast. Making it explicit is required.</font><br><font size=2 face="sans-serif"> Need to
propose a DR against the C standard to get this fixed.</font><br><font size=2 face="sans-serif"> *ToDo: All:
Discuss writing up this issue (email reflector message 14283) as a DR against
C11.</font><br><font size=2 face="sans-serif"> 14280: For function
returns, the value of the return expression is taken to be the value of
the function. No assignment, conversion, etc.</font><br><font size=2 face="sans-serif"> In Annex
F it was said there is a conversion to the type of the return type.</font><br><font size=2 face="sans-serif"> Jim: Our
intention was that this should apply to function returns. Though we hadn't
realized there is no assignment or conversion.</font><br><font size=2 face="sans-serif"> No objections
to the proposed idea for a fix. Will need to create a DR for Part 1.</font><br><font size=2 face="sans-serif"> *ToDo: Jim:
Create a DR for Part 1 for email reflector message 14280.</font><br><font size=2 face="sans-serif"> 14285: Support
for making the macro value dependent on the WANT macro.</font><br><font size=2 face="sans-serif"> *ToDo: DR
for Part 3 with words needed for email reflector message 14285.</font><br><font size=2 face="sans-serif"> 14282: If short
float gets added we may need to revisit the comment in 14293.</font><br><font size=2 face="sans-serif"> This is
a defect right now. The proposed fix seems good with an addition of a footnote
to handle the float case brought up in 14293.</font><br><font size=2 face="sans-serif"> *ToDo: DR
for Part 3 with words needed for email reflector message 14282 first part.</font><br><font size=2 face="sans-serif"> For the
tgmath part:</font><br><font size=2 face="sans-serif"> Change
part 3 only.</font><br><font size=2 face="sans-serif"> *ToDo:
DR for Part 3 with words needed for email reflector message 14282 second
part (tgmath).</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) continued.</font><br><font size=2 face="sans-serif"> The C format specifiers
give what is needed.</font><br><font size=2 face="sans-serif"> Fred: I know of
an implementation that does not round to an infinity (and not raise overflow)
from %A.</font><br><font size=2 face="sans-serif"> Our TS specification
is wrong. The conversion should happen in the character string domain and
not the floating point domain. This is because overflow only happens when
converting to a format. With character strings you cannot have an overflow.</font><br><font size=2 face="sans-serif"> Jim: This
is not a IEEE-754 conversion. This is a C conversion that is an extension
of 754.</font><br><font size=2 face="sans-serif"> David: Don't
want to make every language consider string to IEEE numerical formats.</font><br><font size=2 face="sans-serif"> C explicitly
says if the field width is not large enough for all the digits in the exponent,
the implementation is required to expand the exponent.</font><br><font size=2 face="sans-serif"> Jim:
This is not the case here (re exponent).</font><br><font size=2 face="sans-serif"> Jim: The
rounding and the result don't fit in the internal format. So we round in
the format, then give a representation of that as a character sequence.
IEEE says round as a character sequence.</font><br><font size=2 face="sans-serif"> Rajan: An
analogous case without any TS's.</font><br><font size=2 face="sans-serif"> Jim:
It does it the IEEE way. So different from what we have specified.</font><br><font size=2 face="sans-serif"> David: If
you are writing out and reading it back in again. What do you want to read
back? Not sure...</font><br><font size=2 face="sans-serif"> *ToDo: Group:
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"> Fred: There was
that other case regarding leading zeros I mentioned in passing.</font><br><font size=2 face="sans-serif"> Jim: David
answered that in that considering them as triples, there is no leading
zeros.</font><br><font size=2 face="sans-serif"> Fred: Ex.
0001234, asking for 2 significant digits. Is it 00 or something else?</font><br><font size=2 face="sans-serif"> Jim: Do
you mean encoding?</font><br><font size=2 face="sans-serif"> Fred: Due
to DFP encodings, the leftmost digit is not always the most significant
digit.</font><br><font size=2 face="sans-serif"> Jim: Does
not include leading zeros.</font><br><font size=2 face="sans-serif"> Fred: Question
was regarding the 754 specification.</font><br><font size=2 face="sans-serif"> David: Significant
digits was always specified as first non-zero digit.</font><br><font size=2 face="sans-serif"> Jim: The
number of zeros changes the quantum exponent. 0.0 vs 0.00 for example.</font><br><font size=2 face="sans-serif"> Ian: Trailing
zero's are significant, not leading. Different from binary where you don't
know if trailing digits are significant or not.</font><br><font size=2 face="sans-serif"> Fred will
look at 754 and bring this up again if there is a problem.</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"> Parts 1/2:</font><br><font size=2 face="sans-serif"> Static/constant
rounding mode:</font><br><font size=2 face="sans-serif"> Jim:
More like syntactic sugar from a programmer and implementation point of
view.</font><br><font size=2 face="sans-serif"> Rajan:
Can be very bad performance if implementing this with dynamic rounding.</font><br><font size=2 face="sans-serif"> Part 3:</font><br><font size=2 face="sans-serif"> Allows other
floating types. _Float16 for example.</font><br><font size=2 face="sans-serif"> Rajan: Significant
overhead for each new type (cos, sin, etc. functions need to be added,
encoding/decoding functions, redundant set of functions if the types are
the same as standard types).</font><br><font size=2 face="sans-serif"> Jim: Special
casing for standard types needed for specification.</font><br><font size=2 face="sans-serif"> Allows
importing data for types that are not fully supported (no arithmetic for
example).</font><br><font size=2 face="sans-serif"> Rajan: For
IEEE-754 format implementers, requires _Float{32, 64, 32x} and whatever
long double corresponds to. Can remove that requirement to possibly ease
concerns as to work required? Not advocating it, just proposing it.</font><br><font size=2 face="sans-serif"> Part 4:</font><br><font size=2 face="sans-serif"> Should not
have major conflict with CPLEX's reduction objects since they deal with
collapsing views. They can use our functions if needed for float/double
sum/product reductions.</font><br><font size=2 face="sans-serif"> Rajan: This
part should explicitly be optional. Can discuss the other parts (likely
optional too), but this one has to be.</font><br><font size=2 face="sans-serif"> Part 5:</font><br><font size=2 face="sans-serif"> Pick this
up next time.</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>