[Cfp-interest 2584] Preliminary WG14 IEEE 754-C binding meeting minutes - 2023/01/04

Wed Jan 4 11:00:00 PST 2023

  Attendees: Rajan, Jim, Fred, Mike, David H, Damian, Hans Boehm, Ian

  New agenda items (https://wiki.edg.com/pub/CFP/WebHome/CFP_meeting_agenda_20230104-update.pdf):
    None.

  Previous meeting minutes:
    CFP2563 (Posted on CFP wiki)

  Next Meeting(s):
    January 5, 2023, 4PM UTC – Note that this is tomorrow due to the WG14 mailing deadline!
    ISO Zoom teleconference
    Please notify the group if this time slot does not work.
    Note: The WG14 meeting is January 23-27, 2023

  Carry over action items:
    Done unless specified otherwise.
    Details below in "Carry-over action items results" section.

  Last meeting action items:
    Done unless specified otherwise.
    Details below in “Action items results” section.

  New action items:
    All: Look at NB comments needing conclusions (US26-075, GB157, GB279, GB287)

  C++ liaison:
    Rounding direction specific functions. Discussion below.

  C23 integration:
    CD ballot out (https://wiki.edg.com/pub/CFP/WebHome/ISO-IEC_JTC_1-SC_22_N5777_Text_for_CD_9899.pdf).
    See CFP2558

  Carry-over action items results:
    David H: Get an example for the scaled reduction functions (perhaps by asking Jason or Jim or looking into the IEEE references). - Not done.
      See https://754r.ucbtest.org/background/traps-and-wraps.txt

    David H: Get an example for the augmented arithmetic functions (perhaps by asking Jason or Jim or looking into the IEEE references). - Not done.

  Action items results (from previous meeting):
    Rajan/Jim/Fred: Provide the CD comments to the CFP list for review.
      See CFP2569.

    All: Review CD comments related to CFP.
      See CFP2572, CFP2574-2577
      https://wiki.edg.com/pub/CFP/WebHome/NB_comments_on_CD-JWT-20230102.pdf
      GB7: Third change (6.7.1#16): binary32 is not applicable here so it should be "float" for the first and "IEC 60559 binary32" for the second. - All agreed.
      US6: Mike has checked them all. Agree to the change. N3xxx has the correct font already. - Agreed with the suggested NB comment changes.
      GB63: Mike has checked them all. Agree to the change. - Agreed.
      US75 (US26-075): Real to complex (from N3071):
        Mike: What do existing implementations do with this?
        Jim: There are none. This is new for C.
        Hans: C++ is trying to create new areas constexpr is allowed in. Complex is not C++ so this is not something we have handled.
        Jim: The real to complex should be allowed. - Agreed.
        (Complex to real) Jim: This is a change in value.
        Hans: This is C specific. In C++ it needs to be compile time evaluable for some arguments. Weaker than what is in C.
        Jim: Constraint violation suggested due to value preservation failing. - Agreed.
        Question 4 (Quiet NaNs) Fred: Is NaN even representable in the type?
        Jim: It is since the NaN is there.
        Fred: Earlier we say range is -Inf to Inf without mentioning NaNs.
        Jim: That is for range of representable values. Different use.
        Question 5 (SNaN) Jim: Constraint violation in all cases.
        Fred: To the same type, it should be OK right?
        Jim: Correct.
        Fred: Your answer doesn't talk about same type.
        Jim: Correct, the question didn't ask that. I can note that. - Agreed.
        Question 6 (standard to decimal): Jim: Should not be a constraint violation. - Mostly agreed.
        Question 7 (decimal to standard): Jim: Violation. Losing quantum. - Agreed.
        Mike: Finite should be violation, but others should not.
        Fred: Easier to specify and implement as a whole instead of exception cases.
        Mike: OK. - Mostly agreed.
        Question 8 (quantum exponents) Jim: Change in value so not allowed. - Agreed.
        Main issue: Jim: Only needed if FENV_ACCESS is on.
        Fred: If the value depends on state, it is prohibited.
        Jim: Do you mean "potentially depends on state"?
        Fred: Yes. I wouldn't make it depend on FENV_ACCESS. Just blanket prohibition.
        Mike: That would prohibit most arithmetic.
        Jim: Inexact additions would be prohibited.
        Fred: Agreed. Exact is fine. If it depends on state, the value can wobble.
        Mike: Correct.
        Hans: C++ is going in the other direction like allowing trig functions for constexpr.
        Jim: If the initializer is dependent on state when evaluated at execution time, it is prohibited.
        Mike: Another way of putting it is if the value can change for any reason, it is prohibited.
        Jim: Would the analysis allow changing the value later on?
        Jim: For Fred's, it always depends on state since the default state is a state.
        *No resolution beyond there needs to be a change since it is a problem.
      GB127: Jim: In another place we say the preferred quantum exponent is implementation defined. - Mostly agree.
      GB147: Jim: The floating point annexes weren't structured with merging into other sections, but it seems OK since nothing is said on how the merging is done. - Agreed.
      GB149: No issues. - Agreed.
      GB151: Jim: == should have been "is equivalent to" due to NaNs.
        Mike: These are footnotes so non-normative and sloppy language is fine here. We could just leave the "equivalent" text.
        Fred: The problem is if I is complex instead of imaginary, Infinity * it gives a Nan instead of infinity.
        Jim: Using CMPLX defeats the point of the footnote. By saying "if imaginary types are supported" that works.
        Mike: Just say that formulation can be used. Or we can just delete the footnote.
        - Mostly agreed to Jim's change.
      GB152: No issues. - Agreed.
      *GB153: Jim: Don't see an issue. - Disagree with the NB comment.
      US155: Editorial, not technical - Agreed.
      GB156: Jim: Macros are not pragma expanded. We did have inconsistencies elsewhere as well so better to accept the change. - Agreed.
      *GB157: Possibly not needed. Need to review further.
      GB163: Fred: It is possible an implementation may use an expression that is a valid constant expression but not an arithmetic constant expression.
        - Mostly agreed.
      GB164: Jim: The previous semantics should NOT be restored. It is more important to report the overflow if you get a finite result. - Mostly agreed.
      US42-169: Add the returns section. Similar to 7.24.1.3 - Agreed (add a return section).
      *US43-170: Jim: Both implied, so not normative. – Disagree.
      GB173: No issues. - Agreed.
      US56-187: No issues. - Agreed.
      US57-189: No issues. - Agreed.
      GB229: Jim: If we intended default argument promotions, we wouldn't have added the float versions of the functions. - Agreed.
      GB230: No issues. - Agreed.
      GB267: Mike: Program font vs pretty font. The comment is correct. - Agreed.
      GB268: Jim: If the value is Inf or NaN, the conversion to int would raise an exception. The spec makes it unspecified. - Agreed.
        Jim: Note that F.10.3.7 uses exp while 7.12.6.7 uses p.
      GB269: Generally we do say the infinity cases. - Agreed.
      US68-270/GB271: Jim: 271's wording is better. - Agreed.
      US71-275: Jim: The line doesn't add anything. Suggest deleting. - Agreed (delete).
      GB276: No issues. - Agreed.
      US67-278: No issues. - Mostly agreed.
      GB279: Fred: constexpr should not apply to auto.
        Jim: There is no need for the feature then.
        *Same as US26-75 - Need to discuss further.
      GB286: Jim: For strfromd you don't need the wide version due to composing 2 other functions. This does not apply to strto though, and we need it. They should be added, but unlikely to be added now.
        Rajan: We could say this was missed and should be present. But if we can't do it, it can be in a future standard.
        Jim: Put it in "Future directions". - Agreed (add wide string analogs).
      GB287: Jim: For decimal, hex input is prohibited in the base standard. Annex H allows hexadecimal input for those same functions. Adding the functions seems like a big change at this stage.
        Jim: H.12.2 can introduce strtohex functions. But that seems messy and not right.
        Rajan: We can say it is implementation defined in strtodN whether hex inputs are supported or not. That way Annex H becomes an extension, and allows existing implementations to keep diagnostics if they don't support Annex H.
        Fred: Another option is to allow 7 to allow hex and point to Annex H.
        Jim: We can have a footnote to say it is intended that implementations follow Annex H.
        *Direction is to do implementation defined in section 7 and pointing to Annex H if implemented.
      GB288: Jim: We do need words. "The preferred quantum exponent for the result is zero if it is exactly represented in the type. It is the least possible exponent if it is not exactly represented in the type." - Agreed (needs new words).
      GB292: No issues. - Agreed.
      *US74-303: Jim: Not needed since interchange formats and the least value greater than 1 is normalized. Note that normalized doesn't appear for *_EPSILON for decimal. – Disagree with comment.
      GB322: Jim: Also missing crootn and crsqrt (even the double versions).
        Fred: They are present. - Agreed


    Jim: Clean up participants list on the wiki.
      See CFP2567.

  Other issues:
    Review TS part 4 revision
      See [Cfp-interest 2454] Re: post-C23 update for TS 18661-4


    TS part 5 revision
      See [Cfp-interest 2560] TS 18661-5 revision


    Rounding direction specific functions
      [Cfp-interest 2561] Fwd: Floating point environment


  Others:
    None

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<mailto:rbhakta at us.ibm.com>

IBM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20230104/4de208fc/attachment-0001.htm>