<font size=2 face="sans-serif">2016/12/01, 12:00 EST:</font><br><font size=2 face="sans-serif"><b> Attendees</b>: Rajan, Jim,
Fred, Mike, David C., David H.</font><br><br><font size=2 face="sans-serif"><b> New agenda items:</b></font><br><font size=2 face="sans-serif"> Discussion of email from
WG14 reflector message 14561</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. - Done.</font><br><font size=2 face="sans-serif"> Jim: DR Set 3: Change
positive-signed to non-negative. - Done (discussed later).</font><br><br><font size=2 face="sans-serif"><b> New action items:</b></font><br><font size=2 face="sans-serif"> Jim: Call David Keaton
and ask for advice on how and when to present proposals for Parts 3-5.</font><br><font size=2 face="sans-serif"> Jim: Write up a proposed
TC for DR501 to make the DECIMAL_DIG macro obsolescent.</font><br><font size=2 face="sans-serif"> All: Make sure we're OK
with DDR9/DR11's change.</font><br><font size=2 face="sans-serif"> Jim: Ask the IEEE-754
revision mailing list if the payload for NaN's must be non-negative (0
and up allowed).</font><br><font size=2 face="sans-serif"> Jim: Reflector message
14561: Fix up "macro argument" to something along the lines of
7.25#3.</font><br><br><font size=2 face="sans-serif"><b> Next Meeting:</b></font><br><font size=2 face="sans-serif"> Tuesday January 24th,
2017, 12:00 EDT, 9:00 PST</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"> Fred: There was
discussion about -0/0 on the IEEE chain. Is this something that we need
to bring into the C standard.</font><br><font size=2 face="sans-serif"> David C: fmax/fmin
(C) issues (maxNum, minNum in IEEE): Looking for insights into what to
do.</font><br><font size=2 face="sans-serif"> David H:
Was it a mistake in IEEE 2008? If so, we can remove the item, or add a
new item that does what we want (as a recommendation) so both ways don't
break anyone.</font><br><font size=2 face="sans-serif"> David H: augmented/twoSum
are added and settled down now.</font><br><font size=2 face="sans-serif"> Still issues
with multiple exceptions, like signalling NaNs. Needs to be clarified.</font><br><font size=2 face="sans-serif"> Sub-exceptions
bring up other issues.</font><br><font size=2 face="sans-serif"> Jim: The fmax/fmin
in C adhere to the IEEE-754 operation right now. If it is removed from
IEEE, we'd have to change the binding table.</font><br><font size=2 face="sans-serif"> Mike: Does anyone
claim conformance to the IEEE-754:2008 standard?</font><br><font size=2 face="sans-serif"> David C:
Never saw anyone.</font><br><font size=2 face="sans-serif"> Fred: No
compiler I've seen defines the conformance macro.</font><br><font size=2 face="sans-serif"> Jim: HP
did for Annex F (but that's the IEEE 754:1985 standard).</font><br><br><font size=2 face="sans-serif"> C++ liaison:</font><br><font size=2 face="sans-serif"> No update.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> What should be proposed
for the C standard (C2X):</font><br><font size=2 face="sans-serif"> Current status:</font><br><font size=2 face="sans-serif"> Part 1 and
2 are intended to be included.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Proposals for the
other 3 parts:</font><br><font size=2 face="sans-serif"> Next C meeting
mailing deadline is March 6th, 2017.</font><br><font size=2 face="sans-serif"> We need
to decide what to do by the February meeting.</font><br><font size=2 face="sans-serif"> David H:
How do the other C members feel about the other parts?</font><br><font size=2 face="sans-serif"> Part
3: Seemed to be not wanting to be implemented by some members, but not
real resistance.</font><br><font size=2 face="sans-serif"> Part
4: Neutral opinion. Library so more likely to be accepted.</font><br><font size=2 face="sans-serif"> Part
5: Negative opinion with regards to exception handling (try/catch).</font><br><font size=2 face="sans-serif"> Jim: Since
they will all be optional, others not implementing it should not be too
much of a roadblock.</font><br><font size=2 face="sans-serif"> Part
3 is a wide ranging type so would prefer to see implementation experience.</font><br><font size=2 face="sans-serif"> Fred: A
possible objection to Part 4 is if there is no implementation experience,
do we have all the corner cases handled?</font><br><font size=2 face="sans-serif"> Jim:
tanpi may have an argument (ones we added since it seemed to be omissions).
The other two functions we added were added to the new IEEE-754 revision,
but not this one.</font><br><font size=2 face="sans-serif"> Rajan: We
can propose part 4 as is with the caveat of removing tanpi if desired.</font><br><font size=2 face="sans-serif"> Jim: For
part 5, seems like a regularization of things implementations already do.
This would provide portability. Perhaps separate out try/catch, and possibly
the other parts that change flow control.</font><br><font size=2 face="sans-serif"> Fred: We
can propose part 5 without try/catch.</font><br><font size=2 face="sans-serif"> Jim:
How about break?</font><br><font size=2 face="sans-serif"> Fred: For
part 4, should they functions go in the main body or an annex?</font><br><font size=2 face="sans-serif"> Jim: Like
the TS, some in both the main body or in Annex F. As stated now, they will
stay an optional feature.</font><br><font size=2 face="sans-serif"> Fred: Some
compiler implementers may not have enough knowledge to do the alternate
exception handling.</font><br><font size=2 face="sans-serif"> The
hardware does not support everything. The compiler would have to do the
mapping.</font><br><font size=2 face="sans-serif"> David
H: Same issue with anything else for a compiler as it always maps from
language to hardware.</font><br><font size=2 face="sans-serif"> Fred:
One case is having a user requesting denorms flushed to zero, can be much
slower than expected.</font><br><font size=2 face="sans-serif"> David
H: At some point you have to know what your hardware is capable of.</font><br><font size=2 face="sans-serif"> Jim:
The optimization pragma allows flush to zero, doesn't require it. For alternate
exception handling, it has to be done, so it could require a lot of work.</font><br><font size=2 face="sans-serif"> Jim: Sub-exceptions
is another complexity we need to talk about.</font><br><font size=2 face="sans-serif"> David
H: Perhaps don't suggest this in the first round to the C committee?</font><br><font size=2 face="sans-serif">
Supporting sub-exceptions does require a lot of library and compiler support
since the hardware normally does not support them all.</font><br><font size=2 face="sans-serif"> Jim: Note
that part 5 is optional. Alternate exception handling is an optional part
of part 5, and sub-exceptions are a "should" so triply optional.</font><br><font size=2 face="sans-serif"> *Jim: Call
David Keaton and ask for advice on how and when to present these.</font><br><font size=2 face="sans-serif"> Present
part 3 as is, but not pushed, and make clear the extent of the change,
and have a fallback of referencing it if not accepted</font><br><font size=2 face="sans-serif"> Present
part 4 with tanpi as a possible removal</font><br><font size=2 face="sans-serif"> Present
part 5 without try/catch</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> DRs:</font><br><font size=2 face="sans-serif"> Set 2:</font><br><font size=2 face="sans-serif">
DR501 (DECIMAL_DIG):</font><br><font size=2 face="sans-serif">
For types wider than long double, like the types in
Part 3, allowing DECIMAL_DIG to be larger can handle that.</font><br><font size=2 face="sans-serif">
Jim: Even a committee response saying it can be larger
without a textual change in the standard would be good enough.</font><br><font size=2 face="sans-serif">
Since we have type specific ones (including part 3)
maybe we don't need this.</font><br><font size=2 face="sans-serif">
Fred: The current wording says largest floating type.
So it should be fine.</font><br><font size=2 face="sans-serif">
Jim: You should be able to have wording that
supports Part 3 and C11 without part 3.</font><br><font size=2 face="sans-serif">
If you have a type that is wider than
long double then DECIMAL_DIG would be larger. But C11 as it is only has
the largest floating type as long double so it doesn't conform.</font><br><font size=2 face="sans-serif">
A footnote would be better.</font><br><font size=2 face="sans-serif">
*Jim: We can make it obsolescent since there are type
specific macros already.</font><br><font size=2 face="sans-serif">
DDR9/DR11 (%a formatting):</font><br><font size=2 face="sans-serif">
Need to watch this to make sure the late paper gets
in and doesn't get missed.</font><br><font size=2 face="sans-serif">
*All: Make sure we're OK with DDR9/DR11's change.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Set 3:</font><br><font size=2 face="sans-serif"> DDR1 (November
1 email from Jim re payload with positive floating point integer)/Last
meeting action item:</font><br><font size=2 face="sans-serif"> Precluded
the payload from being zero.</font><br><font size=2 face="sans-serif"> Part
1 says 60559 says the payload is an integer value encoding in the significand.</font><br><font size=2 face="sans-serif">
754 says for decimal that the maximum is a certain value which implicitly
says positive integers?</font><br><font size=2 face="sans-serif"> Fred:
Isn't a payload of 0 for one type of NaN an infinity?</font><br><font size=2 face="sans-serif"> Jim:
Maybe get confirmation of this from 754 before we decide on this here?</font><br><br><font size=2 face="sans-serif"> Other:</font><br><font size=2 face="sans-serif"> WG14 reflector
message 14561 (Joseph Myers):</font><br><font size=2 face="sans-serif"> Jim sent
an email discussing this issue (2016/12/01).</font><br><font size=2 face="sans-serif"> First change
parallels DDR7.</font><br><font size=2 face="sans-serif"> Rajan: Second
change: Does macro argument type make sense? Macro arguments don't have
types since they are substituted during preprocessing and before we have
types.</font><br><font size=2 face="sans-serif"> Need
to match what we say in 7.25#3.</font><br><font size=2 face="sans-serif"> Jim: This
does give the implementation a choice of functions to use (anything that
is wide enough to produce the given result type). Since these are correctly
rounded functions, it doesn't matter which one we pick.</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><BR>