<html><body><p><font size="2" face="sans-serif">Hello,</font><br><br><font size="2" face="sans-serif">Good news! All our papers passed with one exception. N2849 (narrowing conversion functions with tgmath) had a request to make sure we cover other cases such as _Float32x and _Decimal32x. This has been done under N2931.</font><br><br><font size="2" face="sans-serif">Here are the raw notes for our papers (thanks to Fred for taking notes as well):</font><br><br><font size="2" face="sans-serif">5.8.1 Tydeman, *_HAS_SUBNORM==0 implies what? [N 2797] (the green part only, which was skipped at the previous meeting)</font><br><font size="2" face="sans-serif"> Fred: Since the standard does not define what happens whether subnormals are flushed or not, we added this text to define it.</font><br><font size="2" face="sans-serif"> Seacord: Adding positive zero to positive zero is different from +0 to -0.</font><br><font size="2" face="sans-serif"> Fred: Totally different. Existing hardware has the user being able to handle subnormal operands vs results. 4 different modes.</font><br><font size="2" face="sans-serif"> Seacord: That has nothing to do with 754? Just hardware?</font><br><font size="2" face="sans-serif"> Fred: Operations, not operands in 754. It is optional and CFP is not asking C to support it.</font><br><font size="2" face="sans-serif"> Joseph: The 754 is different from what HW does. It is complicated and depends on the rounding mode.</font><br><font size="2" face="sans-serif"> Fred: Doesn't matter for this case. This mainly applies to ARM chips and what's in your cell phone.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"> Straw poll: Does WG14 want N2797 (the green text) in C23?</font><br><font size="2" face="sans-serif"> 15/0/2. Consensus. Goes into C23.</font><br><br><font size="2" face="sans-serif">5.8.2 Tydeman, DFP: Quantum exponent of NaN (version 2) [N 2754]</font><br><font size="2" face="sans-serif"> Fred: Writing tests for my test suite I found a defect in 60559. A set defines specific result for quantum exponents while another section makes it undefined. It is on the IEC list of things to fix, but I don't know if it will ever be fixed since they may never have a new revision. The footnote is what I think it should be as recommended practice.</font><br><font size="2" face="sans-serif"> Seacord: In the footnote, I don't understand the wording as "would be" meaning it is only under certain circumstances so better to say "is a". It can be editorial.</font><br><br><font size="2" face="sans-serif"> Straw poll: Does WG14 want N2754 in C23 (with "would be" changed to "is" in the footnote)?</font><br><font size="2" face="sans-serif"> 17/0/3. Goes into C23.</font><br><br><font size="2" face="sans-serif">5.8.3 Thomas, C23 proposal - Remove default argument promotions for _FloatN types [N 2844]</font><br><font size="2" face="sans-serif"> Seacord: On the surface this sounds strange to me. float is 32-bits and is single precision and takes place in promotion. Why is there interest in not having this promote.</font><br><font size="2" face="sans-serif"> Rajan: Reasonable implementations could consider _Float32 as an almost alias to float, so this would make it harder to implement. Special cases are needed.</font><br><font size="2" face="sans-serif"> Joseph: DR206 states the committee says float _Complex does not promote to double _Complex. They say default argument promotion was only for K&R C. The architecture can do it in the ABI still regardless of the language level. </font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"> Straw poll: Does WG14 want N2844 in C23?</font><br><font size="2" face="sans-serif"> 14/1/2. Goes into C23.</font><br><br><font size="2" face="sans-serif">5.8.4 Thomas, C23 proposal - Revised suggested change from N2716 [N 2847]</font><br><font size="2" face="sans-serif"> Straw poll: Does WG14 want N2847 in C23?</font><br><font size="2" face="sans-serif"> 10/0/5. N2847 goes into C23.</font><br><br><font size="2" face="sans-serif">5.8.5 Thomas, C23 proposal - Type annex tgmath.h narrowing macros with integer args [N 2849]</font><br><font size="2" face="sans-serif"> Rajan: A hole in the tgmath specification for functions that round to a narrower type where integers given for a decimal function ended up being not defined because all integers gives double, not a decimal type. This change allows decimal types for the functions that are decimal.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"> Joseph: Does the fNx, dNx need to be addressed?</font><br><font size="2" face="sans-serif"> Rajan: Yes, it looks like we need to add at least f32x and d32x.</font><br><font size="2" face="sans-serif"> Homework: Look into why the _Float32x and _Decimal32x?</font><br><font size="2" face="sans-serif"> Ballman: Is there a chance this will break anyone?</font><br><font size="2" face="sans-serif"> Rajan: I don't know of anyone other than Joseph.</font><br><font size="2" face="sans-serif"> Joseph: There were various issues for the tgmath rules, but the set here is reasonable. It is unlikely to break users in practice. There may be differences between the TS and C23.</font><br><br><font size="2" face="sans-serif"> ^Action item: CFP to look into _Float32x and _Decimal32x narrowing functions for N2849 for next week.</font><br><br><font size="2" face="sans-serif">5.8.6 Thomas, C23 proposal - 5.2.4.2.2 cleanup-update [N 2879]</font><br><font size="2" face="sans-serif"> Rajan: In the last WG14 meeting, suggestions were made for further refinements to N2806. This paper does those. First it makes the categories of floating point numbers into separate paragraphs. Second, it opens up the model to allow other non-IEEE categories of floating point numbers (better fits double-double).</font><br><br><font size="2" face="sans-serif"> Straw poll: Does WG14 want N2879 in C23?</font><br><font size="2" face="sans-serif"> 13/0/4. Put N2879 into C23.</font><br><br><font size="2" face="sans-serif">5.8.7 Thomas, C23 proposal - overflow and underflow definitions-update [N 2880]</font><br><font size="2" face="sans-serif"> Rajan: Changes here are to help with non-IEEE models, for example, double-double.</font><br><font size="2" face="sans-serif"> The second point here in this paper is to allow reduced precision return values instead of returning HUGE_VAL (which is normalized/full precision).</font><br><font size="2" face="sans-serif"> Due to the above, CFP noticed that the specification of HUGE_VAL is ambiguous. Even if we don't consider non-IEEE formats, there is still an issue: For a return value from a library function that has round to zero, but the maximum number of the type is infinity.</font><br><font size="2" face="sans-serif"> Fourth, the nextup/down functions were intended to allow stepping through values and not intended to get into overflow or rounding.</font><br><font size="2" face="sans-serif"> Finally, "correctly rounded" (see 3.9) is not specified correctly in the case of overflow if the model includes infinities.</font><br><font size="2" face="sans-serif"> The last case is handled in the first change.</font><br><br><font size="2" face="sans-serif"> Jens: Agree with most of the changes, but issues with "however for types with reduced precision..." No mention of a mathematical value beyond which we overflow. What is the overflow threshold?</font><br><br><font size="2" face="sans-serif"> (Scribe note: The following three lines are from Fred Tydeman's notes)</font><br><br><font size="2" face="sans-serif"> Rajan: Where less than full precision.</font><br><font size="2" face="sans-serif"> Joseph: First sentence explains.</font><br><font size="2" face="sans-serif"> Jens: Might need better wording in future after this is added.</font><br><br><font size="2" face="sans-serif"> Straw poll: Does WG14 want N2880 in C23?</font><br><font size="2" face="sans-serif"> 12/0/5. Put N2880 into C23.</font><br><br><font size="2" face="sans-serif">5.8.8 Thomas, C23 proposal - Normal and subnormal classification-update [N 2881]</font><br><font size="2" face="sans-serif"> Rajan: Last meeting WG14 strongly preferred incremental changes to address larger issues. This should complete what N2842 tried to do handling the remaining concern (Josephs about numbers beyond the range of normalized floating point numbers) brought up.</font><br><font size="2" face="sans-serif"> The change that was not yet approved is the sentence starting with "Larger magnitude"</font><br><br><font size="2" face="sans-serif"> (Scribe note: The following three lines are from Fred Tydeman's notes)</font><br><br><font size="2" face="sans-serif"> Fred: Do we need "less than" added?</font><br><font size="2" face="sans-serif"> Joseph: Text is about Super normals.</font><br><font size="2" face="sans-serif"> Fred: No need to add.</font><br><br><font size="2" face="sans-serif"> Straw poll: Does WG14 want N2881 in C23?</font><br><font size="2" face="sans-serif"> 13/0/3. Put N2881 into C23.</font><br><br><font size="2" face="sans-serif"> Alex: Incremental improvements are awesome and this has really helped with progress. Like the pipeline.</font><br><br><font size="2" face="sans-serif">5.8.9 Thomas, C23 proposal - Clarification for max exponent macros-update [N 2882]</font><br><font size="2" face="sans-serif"> Rajan: As requested in the last WG14 meeting, this is the refinement to N2843 that was requested to handle the concerns for double-double that Joseph brought up. This change addresses that by making the wording similar to the FLT_MAX macro to allow larger exponent values for implementations that have larger full precision values in the type that are not normalized.</font><br><br><font size="2" face="sans-serif"> Straw poll: Does WG14 want N2882 in C23?</font><br><font size="2" face="sans-serif"> 15/0/3. Put N2882 into C23.</font><br><br><font size="2" face="sans-serif"> (Scribe note: This comment was from Fred Tydeman's notes. I believe it is the same comment I had in the previous section, 5.8.8, but am including it here as Fred had it recorded in this section)</font><br><br><font size="2" face="sans-serif"> Alex: Like the many small papers with incremental changes. Easier to understand, faster to process.</font><br><br><font size="2" face="sans-serif">Regards,<br><br></font><font size="2" face="sans-serif"><b>Rajan Bhakta</b></font><font size="2" face="sans-serif"><br>z/OS XL C/C++ Compiler Technical Architect<br>ISO C Standards Representative (Canada, USA), PL22.11 Chair<br>C/C++ Compiler Development</font><br><font size="2" face="sans-serif">rbhakta@us.ibm.com</font><br><br><font size="2" face="sans-serif">IBM</font><BR>
<BR>
</body></html>