<html><body><p><font size="2" face="sans-serif"> </font><font size="2" face="sans-serif"><b>Attendees</b></font><font size="2" face="sans-serif">: Rajan, Jim, Fred, 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><font size="2" face="sans-serif"> Mike: I did post a 754 errata page, with 52+ viewers, but no comments. Implies we did it right.</font><br><br><font size="2" face="sans-serif"><b> Carry over action 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 (all done unless specified otherwise below):</b></font><br><font size="2" face="sans-serif"> Fred: WG14 N2714 Add "a" before "NaN" in last bullet.</font><br><font size="2" face="sans-serif"> Fred: Paper didn't get discussed since the backlog was so big.</font><br><font size="2" face="sans-serif"> ^AI: Rajan: Make this a carry over action item.</font><br><br><font size="2" face="sans-serif"> Fred: Default static init [CFP 1990]: rewrite as: zero, and if it has DFP type, the quantum exponent is implementation defined; (not sure about "quantum" here) (look at C std to see if bullet list ends in ; not .)</font><br><font size="2" face="sans-serif"> - Do changes, and submit to WG14.</font><br><font size="2" face="sans-serif"> - N2755 2021/06/20 Tydeman, static initialization of DFP zeros</font><br><font size="2" face="sans-serif"> Fred: Similar. Did not get discussed. It takes a long time for a paper to show up to WG14.</font><br><br><font size="2" face="sans-serif"> Fred: cr_ prefix [CFP 1967] N2715: Submitted to WG14. Make sure last sentence of paragraph is kept when discuss with WG14.</font><br><font size="2" face="sans-serif"> - N2715 2021/05/09 Tydeman, cr_ prefix</font><br><font size="2" face="sans-serif"> Fred: In the queue.</font><br><br><font size="2" face="sans-serif"> Jim: [CFP 1997]: Range error definition as union of overflow and underflow. Change "below" in footnote to "In this subclause".</font><br><font size="2" face="sans-serif"> - Do that change and submit to WG14.Submit to WG14.</font><br><font size="2" face="sans-serif"> - N2745 2021/05/30 Thomas, C23 proposal - range error definition</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"> Jim: [CFP 1997]: Range error definitions of overflow and underflow. Overflow: "ordinary accuracy" not defined, but OK.</font><br><font size="2" face="sans-serif"> - Underflow: exact minimum normal is underflow. Seems wrong. But no better wording.</font><br><font size="2" face="sans-serif"> - Thomas, C23 proposal - overflow and underflow definitions</font><br><font size="2" face="sans-serif"> - N2746 C23 proposal</font><br><font size="2" face="sans-serif"> Jim: See CFP2010. The "or" in there seems confusing, but it can be reconsidered.</font><br><font size="2" face="sans-serif"> Ian: It does seem right to me. Unless there is a better proposal.</font><br><font size="2" face="sans-serif"> Jim: "ordinary accuracy" seems not perfect, but I can't think of anything better.</font><br><font size="2" face="sans-serif"> Rajan: I can see questions on what "ordinary" means.</font><br><font size="2" face="sans-serif"> Jim: Perhaps keep this on the agenda for next time and have people look at it.</font><br><font size="2" face="sans-serif"> ^AI: Jim/Fred/David H: Look at N2746 to see if it can be worded better.</font><br><br><font size="2" face="sans-serif"> Jim: [CFP 1997]: Annex F overflow and underflow</font><br><font size="2" face="sans-serif"> - Reword footnote 403.</font><br><font size="2" face="sans-serif"> - Submit to WG14.</font><br><font size="2" face="sans-serif"> - N2747 2021/05/30 Thomas, C23 proposal - Annex F overflow and underflow</font><br><font size="2" face="sans-serif"> Ian: Seems OK.</font><br><br><font size="2" face="sans-serif"> Jim: [CFP 1997]: feraiseexcept: traps and alternate exceptions.</font><br><font size="2" face="sans-serif"> - Fix “IECC” and submit to WG14.</font><br><font size="2" face="sans-serif"> - N2748 2021/05/30 Thomas, C23 proposal - effects of fenv exception functions</font><br><font size="2" face="sans-serif"> Jim: Only change was fixing a typo of IECC to IEC.</font><br><br><font size="2" face="sans-serif"> Jim: Annex F binding: CFP 1998, CFP 2002</font><br><font size="2" face="sans-serif"> - Add 'however' to F.3</font><br><font size="2" face="sans-serif"> - Redo 7.31.8 reference: Reserves cr_ prefix names for ... N2749 2021/05/30 Thomas, C23 proposal - IEC 60559 binding</font><br><font size="2" face="sans-serif"> Looks good.</font><br><br><font size="2" face="sans-serif"> Rajan: Post to list results of discussion of next steps w.r.t. shorthand for functions in C standard.</font><br><font size="2" face="sans-serif"> Rajan: Next step is to wait for JeanHeyd to integrate the changes into C23. No response to my note asking if there was anything else CFP needed to do.</font><br><br><font size="2" face="sans-serif"> Jim, David, Fred: [CFP 1991]: WG14 N2642. "observation" is weird. Breakup in two sentences. Finite result is implementation defined - footnote: not specific in 754, but a possible definition is 0. Rework and resubmit to WG14.</font><br><font size="2" face="sans-serif"> - N2754 2021/06/20 Tydeman, DFP: Quantum exponent of NaN (version 2)</font><br><font size="2" face="sans-serif"> Fred: In the WG14 queue.</font><br><br><font size="2" face="sans-serif"><b> New Action Items:</b></font><br><font size="2" face="sans-serif"> Jim/Rajan: Look into what we proposed for TS part 4 and the status of it.</font><br><font size="2" face="sans-serif"> Jim: Put the CFP C23 changes summary page for the C++ liaison study group on the agenda for next meeting.</font><br><font size="2" face="sans-serif"> Rajan: Re CFP2024: Ask Paul if there are other values and if it is a real problem.</font><br><font size="2" face="sans-serif"> Fred: Draft a response to the remquo issue brought up in CFP1974.</font><br><font size="2" face="sans-serif"> Fred/Jim: Create a paper re CFP2030 to propose a response.</font><br><font size="2" face="sans-serif"> Rajan: Send N2751 to JeanHeyd.</font><br><br><font size="2" face="sans-serif"><b> Study group logistics</b></font><br><font size="2" face="sans-serif"> Next meeting date: Wednesday, July 21</font><br><font size="2" face="sans-serif"> Same teleconference number and time.</font><br><br><font size="2" face="sans-serif"><b> WG 14 meeting report</b></font><br><font size="2" face="sans-serif"> • [Cfp-interest 2029] WG14 meeting results for CFP papers</font><br><font size="2" face="sans-serif"> • [Cfp-interest 2032] WG14 meeting: Other CFP related items Rajan Bhakta</font><br><font size="2" face="sans-serif"> Rajan: Next WG14 meeting is end of August.</font><br><font size="2" face="sans-serif"> Jim: Any clarifications on new proposals?</font><br><font size="2" face="sans-serif"> Rajan: This was supposed to be the last meeting for new proposals, but now is later (October 15th by Fred).</font><br><font size="2" face="sans-serif"> Fred: Mailing for next meeting is July 30th.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"><b> C++ liaison</b></font><br><font size="2" face="sans-serif"> Inquiry about C++ proposal for “Extended floating-point types and standard names”</font><br><font size="2" face="sans-serif"> Jim: Basic questions about bfloat16 and part 3.</font><br><br><font size="2" face="sans-serif"><b> C23 integration</b></font><br><font size="2" face="sans-serif"> Latest C2X drafts: </font><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf"><font size="2" face="sans-serif">http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf</font></a><font size="2" face="sans-serif"> </font><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2573.pdf"><font size="2" face="sans-serif">http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2573.pdf</font></a><font size="2" face="sans-serif"> </font><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2478.pdf"><font size="2" face="sans-serif">http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2478.pdf</font></a><br><font size="2" face="sans-serif"> Part 1</font><br><font size="2" face="sans-serif"> Part 2</font><br><font size="2" face="sans-serif"> Part 3</font><br><font size="2" face="sans-serif"> Part 4ab</font><br><font size="2" face="sans-serif"> Part 5abcd</font><br><font size="2" face="sans-serif"> IEC 60559:2020 support</font><br><br><font size="2" face="sans-serif"><b> Other issues</b></font><br><font size="2" face="sans-serif"> Implementation defined macro values</font><br><font size="2" face="sans-serif"> - [Cfp-interest 2024] values of FE_TONEAREST... Paul Zimmermann</font><br><font size="2" face="sans-serif"> Ian: Making a fixed value would break at least one of the libraries right?</font><br><font size="2" face="sans-serif"> Jim/Fred: Yes.</font><br><font size="2" face="sans-serif"> Mike: We could recommend the common case.</font><br><font size="2" face="sans-serif"> Jim: We could, but not sure there is one.</font><br><font size="2" face="sans-serif"> Rajan: Doesn't solve the portability problem.</font><br><font size="2" face="sans-serif"> Mike: In the long run it does.</font><br><font size="2" face="sans-serif"> Mike: We could ask Paul to get the information about other libraries instead of us saying anything.</font><br><font size="2" face="sans-serif"> Ian: What is the frequency of use of each of the libraries? It would be unfortunate to have us recommend one over the other.</font><br><font size="2" face="sans-serif"> Ian: What does IBM do?</font><br><font size="2" face="sans-serif"> Rajan: WG14 normally cares about source portability, not binary portability. Some exceptions, but generally not. Perhaps ask if there are other values and if there is any actual user issues with this.</font><br><font size="2" face="sans-serif"> ^AI: Rajan: Re CFP2024: Ask Paul if there are other values and if it is a real problem.</font><br><font size="2" face="sans-serif"> Jim: I believe the initial reason for this was performance!</font><br><br><font size="2" face="sans-serif"> remquo unspecified cases</font><br><font size="2" face="sans-serif"> - [Cfp-interest 1974] remquo( ) Fred J. Tydeman</font><br><font size="2" face="sans-serif"> - [Cfp-interest 1975] Re: remquo( ) David Hough CFP</font><br><font size="2" face="sans-serif"> - [Cfp-interest 1979] Re: remquo( ) Paul Zimmermann</font><br><font size="2" face="sans-serif"> - [Cfp-interest 1983] Re: remquo( ) David Hough CFP</font><br><font size="2" face="sans-serif"> Fred: I suggest we add something to Annex F saying the quotient is unspecified.</font><br><font size="2" face="sans-serif"> Jim: It's not the entire quotient, just the low order bits.</font><br><font size="2" face="sans-serif"> Jim: I got the impression that there should be a different definition if y == 0.</font><br><font size="2" face="sans-serif"> ^AI: Fred: Draft a response to the remquo issue brought up in CFP1974.</font><br><font size="2" face="sans-serif"> Fred: Most implementations use the bottom 3 bits of the quotient. Making it INT_MIN is bad.</font><br><font size="2" face="sans-serif"> Jim: Anyone know of any use of remquo? I think this is a remanent of the old IEEE standard and for use in trig functions.</font><br><font size="2" face="sans-serif"> Mike: We could drop it.</font><br><font size="2" face="sans-serif"> Jim: We could obsolesce it, but not drop it. I don't actually know about the use of it.</font><br><font size="2" face="sans-serif"> Mike: You don't want unspecified or undefined if you don't need them. Anytime you have it, it causes problems for someone.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"> type_HAS_SUBNORM</font><br><font size="2" face="sans-serif"> - [Cfp-interest 2025] FLT_HAS_SUBNORM is 0: what is fpclassify(<subnormal>)? Tydeman</font><br><font size="2" face="sans-serif"> - [Cfp-interest 2026] Re: FLT_HAS_SUBNORM is 0: what is fpclassify(<subnormal>)? David Hough CFP</font><br><font size="2" face="sans-serif"> - [Cfp-interest 2027] Re: FLT_HAS_SUBNORM is 0: what is fpclassify(<subnormal>)? Steve (Numerics) Canon</font><br><font size="2" face="sans-serif"> - [Cfp-interest 2030] Re: FLT_HAS_SUBNORM is 0: what is fpclassify(<subnormal>)? Jim Thomas</font><br><font size="2" face="sans-serif"> Fred: At least one person has said operands vs results should cause a split in the macro. Arm has this issue. I believe they always flush to zero regardless of rounding modes instead of the minimum normal value as IEEE says.</font><br><font size="2" face="sans-serif"> Jim: It is not just results, it is results when there is an underflow signal. It is the only time it happens. Ex. copysign onto a subnormal value doesn't end up zero.</font><br><font size="2" face="sans-serif"> Jim: There is confusion on the bit-representation of things. See Cannon's response re making subnormals non-canonical zeros. This would make HAS_SUBNORM be zero.</font><br><font size="2" face="sans-serif"> Fred: That's what I want. The hardware may do that, but I don't know what the macros do for that implementation.</font><br><font size="2" face="sans-serif"> Jim: If that's what the hardware does, and what it wants the software wants done, that's fine. What do we change? For comparisons, they would all compare equal. Does ARM do that? If they don't do operands but do flush results, then they would treat them as subnormals.</font><br><font size="2" face="sans-serif"> Fred: For ARM, the C macro would have to be -1, not zero. User programs can change the control bits on the fly. They are not protected.</font><br><font size="2" face="sans-serif"> Jim: That's fine. Lots of implementations have that.</font><br><font size="2" face="sans-serif"> Jim: The other model is the 754 abrupt underflow that only affects results and only if there is an underflow signal. That would require saying they support subnormals but requires particular behavior.</font><br><font size="2" face="sans-serif"> Fred: Are exact subnormals underflow? What causes and exact subnormal to underflow? If an underflow does not signal, it is not abrupt.</font><br><font size="2" face="sans-serif"> Jim: An exact subnormal, because it is tiny, has an underflow signal.</font><br><font size="2" face="sans-serif"> Ian: If you had a value that is subnormal, but a bit near the high end of the fraction set, all others being zero. If you divide it by 2 a different bit is set, and the result is exact. I believe all hardware will treat it as an underflow even though it is exact.</font><br><font size="2" face="sans-serif"> Jim: The underflow signal is done for 754.</font><br><font size="2" face="sans-serif"> Ian: Since it is exact, it is not truly an underflow for a human. The hardware knowing that would be very hard.</font><br><font size="2" face="sans-serif"> Jim: The hardware needs to get it right. We're trying to make the C underflow more general than IEEE since it has to deal with other implementations. In C you'll never see a signal without the flag. All you can do is test for the flag. Because there is no alternate exception handling. Abrupt underflow is an alternative exception handling mode.</font><br><font size="2" face="sans-serif"> Fred: If the result is tiny and non-zero, it is underflow. For abrupt, it is flushed (whether exact or not).</font><br><font size="2" face="sans-serif"> Jim: If there is no underflow signal, the result is not signaled (Ex. copysign, nextup)</font><br><font size="2" face="sans-serif"> Fred: nextup of zero?</font><br><font size="2" face="sans-serif"> Jim: nextup does not signal.</font><br><font size="2" face="sans-serif"> Jim: It is only the way the exception is handled that is different. It can handle subnormals so nextup of zero can give a subnormal.</font><br><font size="2" face="sans-serif"> Fred: The purpose of the macro is if a programmer does arithmetic operations, can they get subnormal results. And if they have subnormal operands and do arithmetic on it, is it treated as a value that is non-zero or as a zero. Both have to be supported for a value of the macro to be 1. If either one is true but not the other, it has to be -1.</font><br><font size="2" face="sans-serif"> Fred: Any nextup of a subnormal has to give the minimum normal. nextdown of any subnormal would have to be all bits zero.</font><br><font size="2" face="sans-serif"> Jim: Only if you want canonical results.</font><br><font size="2" face="sans-serif"> Jim: Steve's model is an implementation model. You can't require it.</font><br><font size="2" face="sans-serif"> Rajan: Why not answer this as a clarification request. Say -1 for mixed results and hence the classification macro results for subnormals will be whatever the implementation wants it to be.</font><br><font size="2" face="sans-serif"> Jim: That would mean that IEEE abruptUnderflow would have an indeterminable result.</font><br><font size="2" face="sans-serif"> Fred: Correct.</font><br><font size="2" face="sans-serif"> ^AI: Fred/Jim: Create a paper re CFP2030 to propose a response.</font><br><br><font size="2" face="sans-serif"> Signbit cleanup</font><br><font size="2" face="sans-serif"> - N2751 2021/06/20 Thomas, C23 proposal - signbit cleanup with typo fix</font><br><font size="2" face="sans-serif"> ^AI: Rajan: Send N2751 to JeanHeyd.</font><br><br><font size="2" face="sans-serif"> Others?</font><br><font size="2" face="sans-serif"> None.</font><br><BR>
<BR>
</body></html>