[Cfp-interest 2563] WG14 IEEE 754-C binding meeting minutes 2022/11/16

[Rajan Bhakta]

  Attendees: Rajan, Jim, Damian, David H., Fred, Vivian

  New agenda items (https://wiki.edg.com/pub/CFP/WebHome/CFP_meeting_agenda_20221116-update.pdf):
    Fred: SNAN on Complex to Imaginary conversion (added to the end of the agenda).

  Previous meeting minutes:
    CFP 2551: http://mailman.oakapple.net/pipermail/cfp-interest/2022-October/002565.html (Posted on CFP wiki)

  Next Meeting(s):
    January 4, 2023, 3PM UTC
    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:
    Rajan/Fred/Jim: Provide the CD comments to the CFP list for review.
    All: Review CD comments related to CFP.
    Jim: Clean up the participants list on the wiki.

  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).
    Comments and discussions when the CD ballot comes out must be through the national body, not CFP.
    Our review before the CD: https://mailman.oakapple.net/pipermail/cfp-interest/2022-September/002558.html

  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.
      Fred: Complex multiply/divide examples can be considered for this. David agreed.

  Action items results (from previous meeting):
    Jim/Fred: Re editorial review comment JT-096: Reword "matches" -> "uses" and reword value 2's description to say something like "following the specification for IEC 60559 operations". Also say that it uses the IEC 60559 storage format.
      Jim: I thought we agreed to remove 2. So the action item does not match what we wanted.
      Fred: I think we need to keep 2. Match format but not the operations.
      Fred: The case is they do 654, but don't claim it.
      Jim: Is it useful?
      Fred: I am willing to drop it.
      Jim: Annex F uses "matches" as well.
      Jim: 60559 says interchange format not storage format.
      Fred: Endianness is an issue.
      Jim: I don't think it is relevant here.
      Jim: We could say uses, or uses an IEC 60559 format for storage.
      Rajan: Storage may imply non-register variables.
      Jim: It can be values maybe? I thought we did intend storage.
      Rajan: It talks about a type which is not necessarily on disk or memory.
      Jim: I see that. "Uses" seems to be the best we can do to cover those cases and more.
      Fred: I think it's more distinguishing double-double from 754 stuff.
      Fred: Maybe leave it as is, but change "match" to "uses" only.
      Jim: I did not make any change to the comment about this. Unintentionally (got lost in the shuffle).

    Rajan: I can send David H. and David K. an email seeing what they are asking for to be a valid liaison for IEEE to WG14.
      Done.

    All: Ensure the email addresses on the wiki are up to date. Can send the updated information to Jim Thomas or edit the wiki themselves.
      See next item.

    Jim: Ensure the email addresses on the wiki are up to date.
      Missing Vivian and Damian who will be added.
      Paul Z, Vincent F, David Olsen can be added.

  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
      Jim: Part 5 had 4 features. Standard pragma form. Alternate exception handling may cause issues for freestanding.
        Rajan: As long as we don't mandate this, it shouldn't.
        Jim: This is an extension annex form so it doesn't.
      Fred/Rajan/Vivian: Each set of features should be independent feature test macros (one each for Evaluation methods, Optimization, reproducibility and alternate exception handling).
      Jim: Issue: Do we need that #if macro test line?
        Rajan: The original intent was to not have the C preprocessor evaluate the pragma.
      Issue: STDC pragmas in the right headers?
        Rajan: I don't get the standard pragmas needing header inclusion. Seems a poor mans feature test macro? It is not specific to this TS since it was there for the existing STDC pragmas.
      Issue: Lone footnote?
        Rajan/Vivian: Keep it as a footnote. Seems best as such.
      Issue: Should rsqrt be included above?
        Fred: Makes sense.
        David: Agree.

    Rounding direction specific functions
      [Cfp-interest 2561] Fwd: Floating point environment
      Jim: They seem to have in mind rounding mode specific operations.
      David: Yes, that was the intent to not just have it for whole program or single operation. It is intended to allow cases like critical sections and to have general purpose languages support general purpose programs.
      David: Interval arithmetic lends itself to block based control like upper bounds in one block, lower in another.
      Jim: Cases I brought up was summations of non-negative values (not as a single operation).
      Jim: For C, we'd have to have the extra parameter or separate functions for each rounding direction. It is pretty trivial to write it in C now with the static and dynamic rounding modes.

  Others:
    Fred: Conversion of complex to imaginary with the real part being an SNAN.
    Jim: Is that for C23?
    Fred: No.
    Fred: So is the discard supposed to raise an exception?
    Jim: My recollection is that it is unspecified so implementations can do whatever they want. If we were to recommend something, I would recommend raising invalid.
    Fred: hypot(inf, SNAN) should be similar.
    Jim: For hypot, if you pass a NAN, you get a NAN result.
    Vivian: Since G.4.3#2 says discarded, it should not signal.
    Jim: The specification for SNANS leaves it implementation defined so we don't preclude signaling in this case.
    Fred: For the hypot equivalent, both cases raise an exception, but give different results.
    Jim: We don't specify a same type conversion is an actual IEEE conversion or a copy.
    Fred: It's implementation defined.
    Jim: It seems either one would be OK off the top of my head.
    Fred: F.2.1#6 is what I was referring to.

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/20221116/1e9bb473/attachment-0001.htm>