<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, Ian, Fred, Mike, Damian, David H., </font><br><br><font size="2" face="sans-serif"> </font><font size="2" face="sans-serif"><b>New agenda items</b></font><font size="2" face="sans-serif"> (</font><a href="https://wiki.edg.com/pub/CFP/WebHome/CFP_meeting_agenda_20210721-update2.pdf"><font size="2" face="sans-serif">https://wiki.edg.com/pub/CFP/WebHome/CFP_meeting_agenda_20210721-update2.pdf</font></a><font size="2" face="sans-serif">):</font><br><font size="2" face="sans-serif"> Fred: Request from an implementor to detect tininess before and after rounding.</font><br><br><font size="2" face="sans-serif"><b> Carry-over action items:</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"> Jim: [CFP 1997]: Range error definitions of overflow and underflow.</font><br><br><font size="2" face="sans-serif"><b> Last meeting action items (done unless specified otherwise):</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> New action items:</b></font><br><font size="2" face="sans-serif"> All: Review CFP 2060.</font><br><font size="2" face="sans-serif"> Fred: Submit CFP 2062 to WG14.</font><br><font size="2" face="sans-serif"> Fred: Write up a proposal to remove the *_HAS_SUBNORM macros.</font><br><font size="2" face="sans-serif"> All: Look into the email history to find out why we chose to make float and _Float32 separate and distinct types.</font><br><font size="2" face="sans-serif"> Rajan: See what we can propose for freestanding and IEEE 754 and send it to the CFP mailing list.</font><br><font size="2" face="sans-serif"> Jim: Add Detect tininess before and after rounding to next meetings agenda.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"><b> Next Meeting(s):</b></font><br><font size="2" face="sans-serif"> Same time slot. Note: New day.</font><br><font size="2" face="sans-serif"> Tuesday, August 17th, 2021, 4PM UTC</font><br><font size="2" face="sans-serif"> ISO Zoom teleconference</font><br><font size="2" face="sans-serif"> Please notify the group if this time slot does not work.</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"> CFP C23 changes summary page for the C++ liaison study group [Cfp-interest 2060]</font><br><font size="2" face="sans-serif"> Rajan: Minor updates since.</font><br><font size="2" face="sans-serif"> Mike: What does conditionally added mean?</font><br><font size="2" face="sans-serif"> Rajan: Depends on whether a feature macro is present or not.</font><br><font size="2" face="sans-serif"> Jim: Put conditionally added at the start of part 2 possibly?</font><br><font size="2" face="sans-serif"> Rajan: But the format specifiers have to be there so it is not conditional. Ex. A lint type tool could not diagnose the decimal-floating point format specifier.</font><br><font size="2" face="sans-serif"> *AI*: All: Review CFP 2060.</font><br><br><font size="2" face="sans-serif"><b> C23 integration</b></font><br><font size="2" face="sans-serif"> Latest C2X draft: </font><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2"><font size="2" face="sans-serif">http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2</font></a><font size="2" face="sans-serif">{596,573,478}.pdf also as link on CFP wiki</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> Carry over action items:</b></font><br><font size="2" face="sans-serif"> Fred: WG14 N2714 Add "a" before "NaN" in last bullet</font><br><br><font size="2" face="sans-serif"> Jim: [CFP 1997]: Range error definitions of overflow and underflow.</font><br><font size="2" face="sans-serif"> See N2746 and CFP {2038-69} titled Underflow.</font><br><font size="2" face="sans-serif"> Jim: New definitions for C over/underflow. The underflow case includes exact minimum normalized number. Fred wants to remove that case.</font><br><font size="2" face="sans-serif"> Jim: Previously we had "extraordinary roundoff error" and now the "ordinary accuracy" is just as ill defined. We could add a footnote to try and clarify this saying the functions result doesn't have extreme magnitude or something to that effect.</font><br><font size="2" face="sans-serif"> David: Trying to apply IEEE thinking to non-IEEE implementations. We can't figure it out and we're supposed to be the experts. I think the previous wording is better, but not by much. It doesn't solve anything.</font><br><font size="2" face="sans-serif"> Jim: I used "ordinary accuracy" to avoid mentioning roundoff error.</font><br><font size="2" face="sans-serif"> David/Fred: The 2nd last change in CFP 2080 makes a number that is slightly larger than the minimum normalized number being rounded down an underflow when it wasn't before.</font><br><font size="2" face="sans-serif"> Jim: For the last change, is it OK?</font><br><font size="2" face="sans-serif"> David/Fred: That seems OK.</font><br><font size="2" face="sans-serif"> Fred: The "may" there gives implementations leeway.</font><br><font size="2" face="sans-serif"> Jim: That is a weakness of this specification. Underflow doesn't have to be reported. In a sense all underflows do not have to be reported. A required underflow is given in the specification of the function. This does remove the problem in the previous change from the definition.</font><br><font size="2" face="sans-serif"> Fred: I'm happy with the last change.</font><br><font size="2" face="sans-serif"> David: It may be as good as we could get.</font><br><font size="2" face="sans-serif"> Jim: It is completely up to the implementation on what to do with underflow. So that helps.</font><br><font size="2" face="sans-serif"> Mike: Ordinary accuracy is not defined even in 754.</font><br><font size="2" face="sans-serif"> Jim: The footnote would say the results are not effected by extreme magnitude being ordinary accuracy. We don't have a model to talk about this in real accurate terms.</font><br><font size="2" face="sans-serif"> Mike: If we don't have it, how can a reader or an implementor understand it.</font><br><font size="2" face="sans-serif"> Fred: You have to mention accuracy since a zero result from rounding should be an underflow.</font><br><font size="2" face="sans-serif"> Jim: We can say "without reduced accuracy" at the end?</font><br><font size="2" face="sans-serif"> David: Or even "default accuracy"?</font><br><font size="2" face="sans-serif"> Fred: Or say "not exact zero" meaning an exact zero is not underflow.</font><br><font size="2" face="sans-serif"> Jim: If we can't agree on something, I don't know if it is reasonable for WG14 to do it.</font><br><font size="2" face="sans-serif"> David: "Or when rounding causes the magnitude of the result to increase to the minimum normalized number of the type." could be added.</font><br><font size="2" face="sans-serif"> Jim: This kind of definition is in tandem with the overflow. It would be weird if we used a totally different set of terms and definitions from overflow.</font><br><font size="2" face="sans-serif"> Rajan: Before Mike and David leave, please post any new wordings you can think of that would be better for this to the CFP mailing list.</font><br><font size="2" face="sans-serif"> Mike/David: Yes, agreed.</font><br><br><font size="2" face="sans-serif"><b> Previous meeting 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"> See CFP 2056.</font><br><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><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"> See CFP 2024.</font><br><font size="2" face="sans-serif"> Paul asked us to drop the issue.</font><br><font size="2" face="sans-serif"> Ian: Should we document this may be an incompatibility?</font><br><font size="2" face="sans-serif"> Rajan: No, since there are other ones like this. Ex. ERANGE, etc. which can have different values between implementations. It allows flexibility.</font><br><font size="2" face="sans-serif"> Ian: OK, makes sense.</font><br><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"> See CFP {1974-2062} titled remquo</font><br><font size="2" face="sans-serif"> *AI*: Fred: Submit CFP 2062 to WG14.</font><br><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"> See CFP {2025-2070} titled "Subnormals" or "FLT_HAS_SUBNORM" </font><br><font size="2" face="sans-serif"> Jim: CFP2070: -1, 0 and 1 stay the same functionally. 2 and 4 are new categories.</font><br><font size="2" face="sans-serif"> Fred: I like this.</font><br><font size="2" face="sans-serif"> Damian: Seems orthogonal. So I like it.</font><br><font size="2" face="sans-serif"> Rajan: Afraid this may open up a rabbits hole.</font><br><font size="2" face="sans-serif"> Fred: From ARM and Intel, they have control bits that say flush operands and one for results.</font><br><font size="2" face="sans-serif"> Damian: What other CPU's do we need to worry about?</font><br><font size="2" face="sans-serif"> Rajan: z as well.</font><br><font size="2" face="sans-serif"> Fred: abs and negate never flush even in flushing mode.</font><br><font size="2" face="sans-serif"> Jim: Those generally are not arithmetical operations, they are bit operations. The "typically" is there to cover that as well.</font><br><font size="2" face="sans-serif"> Damian: Does this cover what RISC 5 does as well?</font><br><font size="2" face="sans-serif"> Jim: I don't know what RISC 5 does.</font><br><font size="2" face="sans-serif"> Damian: Neither do I.</font><br><font size="2" face="sans-serif"> David: There is an escape clause so it should cover all cases. Also the default rounding mode shouldn't be the default execution mode. To take into account the various flush bits in various architectures.</font><br><font size="2" face="sans-serif"> Jim: They could be regarded as rounding or not.</font><br><font size="2" face="sans-serif"> David: It is not intended to be dynamic is it?</font><br><font size="2" face="sans-serif"> Fred: Too late for that, but it would have been nice if it was.</font><br><font size="2" face="sans-serif"> David: I favor removing it from the draft.</font><br><font size="2" face="sans-serif"> Fred: This came from a user or implementor.</font><br><font size="2" face="sans-serif"> Jim: I took it as what am I supposed to set it to?</font><br><font size="2" face="sans-serif"> David: I would say execution mode or runtime mode. Whichever is more commonly used in the standard.</font><br><font size="2" face="sans-serif"> Jim: Is it clear?</font><br><font size="2" face="sans-serif"> Rajan: No, the "typically" is too hand wavy to give a good result on both implementation and user side.</font><br><font size="2" face="sans-serif"> David: Yes, agree.</font><br><font size="2" face="sans-serif"> Ian: Anything other than abs/neg/-abs?</font><br><font size="2" face="sans-serif"> Jim: I would be surprised if everything, all libraries were consistent.</font><br><font size="2" face="sans-serif"> Jim: The current definition is not clear in 2 or 3 different ways. It is in flux in terms of technology and implementations. Doesn't seem important to standardize it in this way.</font><br><font size="2" face="sans-serif"> Mike: Makes sense.</font><br><font size="2" face="sans-serif"> David: 0 conforms completely to IEEE. 1 conforms to alternate exception handling. In fact, you could remove 1 and just make it that it has IEEE or not. First preference is removal.</font><br><font size="2" face="sans-serif"> Fred: I guess we can propose removal.</font><br><font size="2" face="sans-serif"> Jim: It does keep the questions for implementations on what they do for issubnormal, nextafter, etc.</font><br><font size="2" face="sans-serif"> *AI*: Fred: Write up a proposal to remove the *_HAS_SUBNORM macros.</font><br><br><font size="2" face="sans-serif"> Rajan: Send N2751 to JeanHeyd.</font><br><font size="2" face="sans-serif"> See N2751.</font><br><br><font size="2" face="sans-serif"><b> Other issues:</b></font><br><font size="2" face="sans-serif"> Issues with float and _Float32 being different types</font><br><font size="2" face="sans-serif"> See SC22WG14.19485, 19487, 19488, 19491, 19492</font><br><font size="2" face="sans-serif"> Jim: A concern I heard was passing an array of _Float32 to a function in a library that takes float arrays.</font><br><font size="2" face="sans-serif"> Rajan: With the same representation and alignment in practice, C++ -> C should work.</font><br><font size="2" face="sans-serif"> Jim: If C++ makes them the same type, would there be any issue?</font><br><font size="2" face="sans-serif"> Rajan: In practice, I can't see an issue.</font><br><font size="2" face="sans-serif"> Jim: I think _Complex and other issues with typedef made us consider it separate types.</font><br><font size="2" face="sans-serif"> Fred: I wonder if Joseph Myers would have issues with this.</font><br><font size="2" face="sans-serif"> Jim: He was. In earlier drafts we didn't have it clear and he wanted it clear.</font><br><font size="2" face="sans-serif"> *AI*: All: Look into the email history to find out why we chose what we did.</font><br><br><font size="2" face="sans-serif"> Issues with free-standing implementations</font><br><font size="2" face="sans-serif"> See SC22WG14.19444, 19445</font><br><font size="2" face="sans-serif"> Rajan: We really should not have brought in TLS anything or locale anything into freestanding.</font><br><font size="2" face="sans-serif"> Jim: The numeric conversion functions should also be allowed to not have errno.</font><br><font size="2" face="sans-serif"> Rajan: The decimal point and whitespace is an issue for freestanding due to bringing in locales.</font><br><font size="2" face="sans-serif"> Jim: Without the str* functions you couldn't fully conform to the spec for freestanding. We could nail down the whitespace characters and the decimal point character. Or remove whitespace and nail down the decimal point character.</font><br><font size="2" face="sans-serif"> *AI*: Rajan: See what we can propose for freestanding and IEEE 754.</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>
<BR>
</body></html>