[Cfp-interest 2366] WG14 2022-01 Meeting summary for CFP

[Rajan Bhakta]

Hello,

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.

Here are the raw notes for our papers (thanks to Fred for taking notes as
well):

5.8.1 Tydeman, *_HAS_SUBNORM==0 implies what? [N 2797] (the green part
only, which was skipped at the previous meeting)
  Fred: Since the standard does not define what happens whether subnormals
are flushed or not, we added this text to define it.
  Seacord: Adding positive zero to positive zero is different from +0 to
-0.
  Fred: Totally different. Existing hardware has the user being able to
handle subnormal operands vs results. 4 different modes.
  Seacord: That has nothing to do with 754? Just hardware?
  Fred: Operations, not operands in 754. It is optional and CFP is not
asking C to support it.
  Joseph: The 754 is different from what HW does. It is complicated and
depends on the rounding mode.
  Fred: Doesn't matter for this case. This mainly applies to ARM chips and
what's in your cell phone.

  Straw poll: Does WG14 want N2797 (the green text) in C23?
    15/0/2. Consensus. Goes into C23.

5.8.2 Tydeman, DFP: Quantum exponent of NaN (version 2) [N 2754]
  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.
  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.

  Straw poll: Does WG14 want N2754 in C23 (with "would be" changed to "is"
in the footnote)?
    17/0/3. Goes into C23.

5.8.3 Thomas, C23 proposal - Remove default argument promotions for _FloatN
types [N 2844]
  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.
  Rajan: Reasonable implementations could consider _Float32 as an almost
alias to float, so this would make it harder to implement. Special cases
are needed.
  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.

  Straw poll: Does WG14 want N2844 in C23?
    14/1/2. Goes into C23.

5.8.4 Thomas, C23 proposal - Revised suggested change from N2716 [N 2847]
  Straw poll: Does WG14 want N2847 in C23?
    10/0/5. N2847 goes into C23.

5.8.5 Thomas, C23 proposal - Type annex tgmath.h narrowing macros with
integer args [N 2849]
  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.

  Joseph: Does the fNx, dNx need to be addressed?
  Rajan: Yes, it looks like we need to add at least f32x and d32x.
    Homework: Look into why the _Float32x and _Decimal32x?
  Ballman: Is there a chance this will break anyone?
  Rajan: I don't know of anyone other than Joseph.
  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.

  ^Action item: CFP to look into _Float32x and _Decimal32x narrowing
functions for N2849 for next week.

5.8.6 Thomas, C23 proposal - 5.2.4.2.2 cleanup-update [N 2879]
  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).

  Straw poll: Does WG14 want N2879 in C23?
    13/0/4. Put N2879 into C23.

5.8.7 Thomas, C23 proposal - overflow and underflow definitions-update [N
2880]
  Rajan: Changes here are to help with non-IEEE models, for example,
double-double.
  The second point here in this paper is to allow reduced precision return
values instead of returning HUGE_VAL (which is normalized/full precision).
  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.
  Fourth, the nextup/down functions were intended to allow stepping through
values and not intended to get into overflow or rounding.
  Finally, "correctly rounded" (see 3.9) is not specified correctly in the
case of overflow if the model includes infinities.
  The last case is handled in the first change.

  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?

  (Scribe note: The following three lines are from Fred Tydeman's notes)

  Rajan:  Where less than full precision.
  Joseph:  First sentence explains.
  Jens:  Might need better wording in future after this is added.

  Straw poll: Does WG14 want N2880 in C23?
    12/0/5. Put N2880 into C23.

5.8.8 Thomas, C23 proposal - Normal and subnormal classification-update [N
2881]
  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.
  The change that was not yet approved is the sentence starting with
"Larger magnitude"

  (Scribe note: The following three lines are from Fred Tydeman's notes)

  Fred: Do we need "less than" added?
  Joseph: Text is about Super normals.
  Fred:  No need to add.

  Straw poll: Does WG14 want N2881 in C23?
    13/0/3. Put N2881 into C23.

  Alex: Incremental improvements are awesome and this has really helped
with progress. Like the pipeline.

5.8.9 Thomas, C23 proposal - Clarification for max exponent macros-update
[N 2882]
  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.

  Straw poll: Does WG14 want N2882 in C23?
    15/0/3. Put N2882 into C23.

  (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)

  Alex: Like the many small papers with incremental changes.  Easier to
understand, faster to process.

Regards,

Rajan Bhakta
z/OS XL C/C++ Compiler Technical Architect
ISO C Standards Representative (Canada, USA), PL22.11 Chair
C/C++ Compiler Development
rbhakta at us.ibm.com

IBM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20220209/c0257f0a/attachment.htm>