<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, Damian, Mike, Ian, David O., David H.</font><br><br><font size="2" face="sans-serif"><b> New agenda items (</b></font><a href="https://wiki.edg.com/pub/CFP/WebHome/CFP_meeting_agenda_20211013-update.pdf"><font size="2" face="sans-serif"><b>https://wiki.edg.com/pub/CFP/WebHome/CFP_meeting_agenda_20211013-update.pdf</b></font></a><font size="2" face="sans-serif"><b>):</b></font><br><font size="2" face="sans-serif"> None</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 (done unless specified otherwise, details below):</b></font><br><font size="2" face="sans-serif"> Jim: Propose new wording for N2716's change that WG14 did not accept as is.</font><br><font size="2" face="sans-serif"> Rajan: Get a document number for CFP2140 and send an updated document to CFP before WG14.</font><br><font size="2" face="sans-serif"> Jim: Put the formulas into CFP2130's text and show CFP before submitting it to WG14.</font><br><font size="2" face="sans-serif"> Jim: Reword the footnote for CFP2153 and show it to CFP before submitting it to WG14.</font><br><font size="2" face="sans-serif"> Jim: Send out a change to CFP changing the wording of the FLT_MAX_EXP family of macros to say they are for normalized numbers.</font><br><font size="2" face="sans-serif"> Anyone: Look into the use of the term "floating-point number".</font><br><font size="2" face="sans-serif"> Rajan: Get back to Aaron about the FLT_EVAL_METHOD constant value question and point him to part 5 of the TS which does have changing values.</font><br><font size="2" face="sans-serif"> All: Look at CFP2136 and respond within a week.</font><br><font size="2" face="sans-serif"> Jim: Submit a paper to remove the promotion rules as per discussion in CFP2141.</font><br><font size="2" face="sans-serif"> Jim: Propose the change in CFP2154 to WG14.</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 INFINITY macro paper to define INFINITY iff infinities exist in type float, and as an alternative, do what is in the current paper.</font><br><font size="2" face="sans-serif"> Rajan: Bring up CFP's position in WG14's liaison report on not proposing double and long double INFINITY macros despite it being brought up. If WG14 wants it, let us (CFP) know.</font><br><font size="2" face="sans-serif"> Jim: Change N2716's alternative wording proposal to replace the second "=" in the example with "yields" and the "page 450" with the section, sub-clause number.</font><br><font size="2" face="sans-serif"> Jim: Look at the changed text and why some unintentional underlining is present in C23_proposal_-_Normal_and_subnormal_classification-20211008.pdf (Ex. emax).</font><br><br><font size="2" face="sans-serif"><b> Next Meeting(s):</b></font><br><font size="2" face="sans-serif"> Note: New day for this meeting only.</font><br><font size="2" face="sans-serif"> Same time slot.</font><br><font size="2" face="sans-serif"> Tuesday, November 23rd, 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><br><font size="2" face="sans-serif"> November 10th, 2021 reserved as a potential date as well at the same time in case we need it.</font><br><br><font size="2" face="sans-serif"> Upcoming WG14 meetings:</font><br><font size="2" face="sans-serif"> November 15-19, 2021, virtual, 14:30-18:00 UTC each day</font><br><font size="2" face="sans-serif"> Mailing deadline: October 15th, 2021 (Document number requests due October 8th, 2021)</font><br><font size="2" face="sans-serif"> January 31-February 4, 2022, Portland, Oregon, US (Tentative)</font><br><font size="2" face="sans-serif"> Mailing deadline: December 31, 2021</font><br><font size="2" face="sans-serif"> July 11-15, 2022, Strasbourg, France (Tentative)</font><br><font size="2" face="sans-serif"> Mailing deadline: June 10, 2022</font><br><br><font size="2" face="sans-serif"><b> C++ Liaison:</b></font><br><font size="2" face="sans-serif"> WG21's SC22 special meeting about C/C++ compatibility (See CFP2224):</font><br><font size="2" face="sans-serif"> David O: The topic of discussion was the C++ proposal and the interaction with C. Re the new annex. Mostly set. Nothing that C FP needs to follow up on. Naming with _F* names in C++ is still muddled. For arithmetic conversions, we want the interchange type vs the standard type. This is being changed now in the C++ proposal to match C. Implicit conversions difference is staying since it is compile time.</font><br><font size="2" face="sans-serif"> Rajan: My interpretation was the objection to the _Float* name is really just not liking the name, not a technical reason behind it.</font><br><font size="2" face="sans-serif"> David O: Yes, there was some confusion that was addressed. The objection to keywords was adding it to the grammar I believe, and having them optional is not currently previously available in C++. Also having it in the global namespace was an objection. C++ does not like typedefs in the global namespace.</font><br><font size="2" face="sans-serif"> Jim: I attempted to explain the reason and meaning of the _t C names. I don't think anything came of that. Let me know if you need help with this for C++.</font><br><font size="2" face="sans-serif"> David O: I believe there was a poll to change the _t names in C++ but it failed. I plan on keeping it with different meanings between the languages.</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"> IEC 60559:2020 support</font><br><font size="2" face="sans-serif"> Jim: Still no new draft.</font><br><font size="2" face="sans-serif"> Jim: In the future, we should just focus on what's wrong, vs what is unclear or new features. Is it a known problem for users or implementors? If not, it would be hard for us to consider it. Clear editorial corrections should be fine.</font><br><font size="2" face="sans-serif"> Jim: At some point, we'll have to review C23 with our changes.</font><br><font size="2" face="sans-serif"> Rajan: Also the TS updates rebased on C23.</font><br><br><font size="2" face="sans-serif"><b> Action item resolutions:</b></font><br><font size="2" face="sans-serif"> Jim: Propose new wording for N2716's change that WG14 did not accept as is (</font><a href="https://wiki.edg.com/pub/CFP/WebHome/C23_proposal_-_Revised_suggested_change_from_N2716-"><font size="2" face="sans-serif">https://wiki.edg.com/pub/CFP/WebHome/C23_proposal_-_Revised_suggested_change_from_N2716-</font></a><font size="2" face="sans-serif">20211008.pdf):</font><br><font size="2" face="sans-serif"> Rajan: Like it, avoids the equal/numerically equal issues.</font><br><font size="2" face="sans-serif"> Jim: The second = in the example should be "yields".</font><br><font size="2" face="sans-serif"> David H: Can use a right arrow.</font><br><font size="2" face="sans-serif"> Jim: That works for transformations, and this is not.</font><br><font size="2" face="sans-serif"> All: "yields" seems good.</font><br><font size="2" face="sans-serif"> Jim: Change the page number to a subclass?</font><br><font size="2" face="sans-serif"> Ian: Agreed.</font><br><font size="2" face="sans-serif"> *AI*: Jim: Change N2716's alternative wording proposal to replace the second "=" in the example with "yields" and the "page 450" with the section, sub-clause number.</font><br><br><font size="2" face="sans-serif"> Rajan: Get a document number for CFP2140 and send an updated document to CFP before WG14 (See CFP2165, N2823):</font><br><font size="2" face="sans-serif"> Rajan: Sent out to WG14 as N2823.</font><br><br><font size="2" face="sans-serif"> Jim: Put the formulas into CFP2130's text and show CFP before submitting it to WG14 (</font><a href="https://wiki.edg.com/pub/CFP/WebHome/C23_proposal_-_Normal_and_subnormal_classification-"><font size="2" face="sans-serif">https://wiki.edg.com/pub/CFP/WebHome/C23_proposal_-_Normal_and_subnormal_classification-</font></a><font size="2" face="sans-serif">20211008.pdf):</font><br><font size="2" face="sans-serif"> Rajan: See some unintentional underlining. Fred does as well.</font><br><font size="2" face="sans-serif"> Jim: Not intended. I will look at it.</font><br><font size="2" face="sans-serif"> *AI*: Jim: Look at the changed text and why some unintentional underlining is present in C23_proposal_-_Normal_and_subnormal_classification-20211008.pdf.</font><br><br><font size="2" face="sans-serif"> Jim: Reword the footnote for CFP2153 and show it to CFP before submitting it to WG14 (</font><a href="https://wiki.edg.com/pub/CFP/WebHome/C23_proposal_-_Clarification_about_expression_transformations-20211003.pdf"><font size="2" face="sans-serif">https://wiki.edg.com/pub/CFP/WebHome/C23_proposal_-_Clarification_about_expression_transformations-20211003.pdf</font></a><font size="2" face="sans-serif">):</font><br><font size="2" face="sans-serif"> Fred: Looks good.</font><br><font size="2" face="sans-serif"> Ian: The compilers I worked on at IBM were modified to have an option to have strict or not. Including sub-options to tune it.</font><br><br><font size="2" face="sans-serif"> Jim: Send out a change to CFP changing the wording of the FLT_MAX_EXP family of macros to say they are for normalized numbers (</font><a href="https://wiki.edg.com/pub/CFP/WebHome/C23_proposal_-_Clarification_for_max_exponent_macros-"><font size="2" face="sans-serif">https://wiki.edg.com/pub/CFP/WebHome/C23_proposal_-_Clarification_for_max_exponent_macros-</font></a><font size="2" face="sans-serif">20211002.pdf):</font><br><font size="2" face="sans-serif"> Fred: Now you are mixing max float which does not have to be normalized.</font><br><font size="2" face="sans-serif"> Jim: We saw there is no consistency in the naming of these. We haven't chose to change anything for consistency.</font><br><font size="2" face="sans-serif"> Fred: It only matters for double double. I don't know if it has any numbers bigger than the maximum normalized.</font><br><font size="2" face="sans-serif"> Jim: I believe it does.</font><br><font size="2" face="sans-serif"> Fred: If both parts are double max, is that a valid number People said no.</font><br><font size="2" face="sans-serif"> Ian: Depends on the implementations, the original by IBM on AIX did, while the GCC on linux one didn't. GCC did a lot of instructions to make the first part be the same as a double which changed the semantics.</font><br><font size="2" face="sans-serif"> Jim: My sense is (examples not coming to mind right now) that examples are obvious if you don't require the form for double double, but also examples if you do, but more subtle.</font><br><font size="2" face="sans-serif"> Jim: The rationale paragraph right before the change should cover what Fred is talking about as to why.</font><br><font size="2" face="sans-serif"> Fred: For FLT_EPSILON we did change it in C99.</font><br><font size="2" face="sans-serif"> Jim: Unfortunately this was done one at a time. It wasn't done everywhere.</font><br><font size="2" face="sans-serif"> Fred: We'll see if anyone else objects. Joseph Myers may notice and object.</font><br><font size="2" face="sans-serif"> No objections to submit this.</font><br><br><font size="2" face="sans-serif"> Anyone: Look into the use of the term "floating-point number" (See Cfp-interest 2110):</font><br><font size="2" face="sans-serif"> Skipping.</font><br><br><font size="2" face="sans-serif"> Rajan: Get back to Aaron about the FLT_EVAL_METHOD constant value question and point him to part 5 of the TS which does have changing values (See CFP2166,2170):</font><br><font size="2" face="sans-serif"> Rajan: Aaron was happy with this.</font><br><font size="2" face="sans-serif"> Jim: Compiler magic can enable #if/#elif with FLT_EVAL_METHOD if they wanted to.</font><br><font size="2" face="sans-serif"> Rajan: True, but generally not talked about and doesn't work well with preprocessing separately.</font><br><br><font size="2" face="sans-serif"> All: Look at CFP2136 and respond within a week (ttps://wiki.edg.com/pub/CFP/WebHome/C23_proposal_-_Type_annex_tgmath.h_narrowing_macros_with_integer_args-20211008.pdf):</font><br><font size="2" face="sans-serif"> Looks good.</font><br><br><font size="2" face="sans-serif"> Jim: Submit a paper to remove the promotion rules as per discussion in CFP2141 (</font><a href="https://wiki.edg.com/pub/CFP/WebHome/C23_proposal_-_Remove_default_argument_promotions_for__FloatN_types-20211008.pdf"><font size="2" face="sans-serif">https://wiki.edg.com/pub/CFP/WebHome/C23_proposal_-_Remove_default_argument_promotions_for__FloatN_types-20211008.pdf</font></a><font size="2" face="sans-serif">):</font><br><font size="2" face="sans-serif"> Looks good.</font><br><br><font size="2" face="sans-serif"> Jim: Propose the change in CFP2154 to WG14 (</font><a href="https://wiki.edg.com/pub/CFP/WebHome/C23_proposal_-_feraiseexcept_update-20211010.pdf"><font size="2" face="sans-serif">https://wiki.edg.com/pub/CFP/WebHome/C23_proposal_-_feraiseexcept_update-20211010.pdf</font></a><font size="2" face="sans-serif">):</font><br><font size="2" face="sans-serif"> Looks good.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"><b> Other issues:</b></font><br><font size="2" face="sans-serif"> Contradiction about INFINITY macro (</font><a href="https://wiki.edg.com/pub/CFP/WebHome/C23_proposal_-_Contradiction_about_INFINITY_macro-"><font size="2" face="sans-serif">https://wiki.edg.com/pub/CFP/WebHome/C23_proposal_-_Contradiction_about_INFINITY_macro-</font></a><font size="2" face="sans-serif">20211010.pdf):</font><br><font size="2" face="sans-serif"> Jim: The iff INFINITY is present, define it, could follow something like the NAN macros. That would allow INFINITY to be a feature test macro. This would be a substantive changed. I could also break code that depended on UB in a certain way. Is what we have OK?</font><br><font size="2" face="sans-serif"> Fred: The character sequence could be 1E9999?</font><br><font size="2" face="sans-serif"> Jim: Yes.</font><br><font size="2" face="sans-serif"> Rajan: This disallows the "(const float)1E9999" for example.</font><br><font size="2" face="sans-serif"> Fred: You could add in a trailing 'f' to make it a literal.</font><br><font size="2" face="sans-serif"> Jim: I don't thing having the cast makes it a constant. It would not be allowed.</font><br><font size="2" face="sans-serif"> Fred: The existing wording, says INFINITY has to expand to a constant expression which allows the cast.</font><br><font size="2" face="sans-serif"> Damian: Are we allowing this to be an expression?</font><br><font size="2" face="sans-serif"> Jim: The problem is in the 'else' clause which doesn't have the INFINITY. My first attempt was to say "else to a constant expression".</font><br><font size="2" face="sans-serif"> Fred: Can make the second change into "constant expression"?</font><br><font size="2" face="sans-serif"> Jim: Makes it not read well in terms of "character sequence in the form of a constant expression". Not sure why my previous wording was changed (from else constant expression).</font><br><font size="2" face="sans-serif"> Rajan: The 1E999 is a double type which can hold the value, and when converted to a float, it is still a constant expression which had that value become an infinity.</font><br><font size="2" face="sans-serif"> Ian: Perhaps "the constant in the evaluation format of type float"? If the evaluation format is double, the evaluation format is double, of type float.</font><br><font size="2" face="sans-serif"> Jim: That is getting into the second problem. Lets try to solve the first one.</font><br><font size="2" face="sans-serif"> Fred: If you don't have INFINITY, then it won't work. If you do have an INFINITY you don't have an issue.</font><br><font size="2" face="sans-serif"> Jim: Yes, if you have an INFINITY, there is no issue.</font><br><font size="2" face="sans-serif"> Jim: A problem with what was proposed can't be done at translation time if FENV_ACCESS is on.</font><br><font size="2" face="sans-serif"> Jim: We could change it to make INFINITY defined iff INFINITY exists. Do we want a backup if it fails?</font><br><font size="2" face="sans-serif"> Fred: We could have a feature test macro to say if infinities exist.</font><br><font size="2" face="sans-serif"> Jim: INFINITY could become the feature test macro.</font><br><font size="2" face="sans-serif"> *AI*: Jim: Update the INFINITY macro paper to define INFINITY iff infinities exist in type float, and as an alternative, do what is in the current paper.</font><br><br><font size="2" face="sans-serif"> Ian: It does bring up the question if every floating point type should have INFINITY.</font><br><font size="2" face="sans-serif"> Damian: The float constant that is infinity, will always be infinity in double and long double.</font><br><font size="2" face="sans-serif"> Jim: This is true. But Ian brought up CELL which has no infinity for float, but it is present for double.</font><br><font size="2" face="sans-serif"> Jim: Should we define double infinity and long double infinity?</font><br><font size="2" face="sans-serif"> Ian: Is there any current development on Cell or changes coming?</font><br><font size="2" face="sans-serif"> Jim: I would suggest not proposing this. It would be a new feature. If WG14 wants this they could ask us.</font><br><font size="2" face="sans-serif"> *AI*: Rajan: Bring up CFP's position in WG14's liaison report on not proposing double and long double INFINITY macros despite it being brought up. If WG14 wants it, let us (CFP) know.</font><br><br><font size="2" face="sans-serif"> Wrapping up proposals (See CFP2203,2223):</font><br><font size="2" face="sans-serif"> </font><br><br><font size="2" face="sans-serif"><b> Others?</b></font><br><font size="2" face="sans-serif"> David H: There will be a virtual ARITH conference and the next one will be live.</font><BR>
<BR>
</body></html>