[Cfp-interest] WG14 IEEE 754-C binding meeting minutes 2014/10/16

[Rajan Bhakta]

2014/10/16, 12:00 EST:
  Attendees: Rajan, Jim, David, Fred, Ian

  New agenda items:
    WG14 liaison reporting - Rajan and Fred going (See part 5)
      No new documents to present.
      If the C standard is moved to Latex, we have a chance at applying 
the changes to C11.
      *ToDo: Rajan/Fred: Find out what is happening with the LaTeX 
migration in terms of timing.

      New words for liaison reporting:
        Parts 3 and 4 are ready for final ballot pending the resolution of 
the comments received in the PDTS as decided upon in this meeting.
        Part 5 is proceeding using the original #pragma syntax plan 
because there is no approval for any of the alternatives proposed. See 
paper n1841 for this discussion.
          The other aspects of Part 5 are being discussed as well.

    Part 5 email discussion (See part 5)

  Sticky action items:
    David: Part 5: Complete exception specification with the full syntax 
dealing with scope and sub-exceptions. Include a discussion document with 
reasons choices and alternatives. - Partially done (more of an outline. 
Sent on 2014/05/12). Keep open.
    David: Part 5: SUBSTITUTEXOR -> SUBSTITUTE_XOR. Pending issue 
resolution. - Leave open

  Last meeting action items:
    ToDo: Part 3: Jim: Formatting to accurately reflect source document. - 
Not done. Close it anyways since it is not present in the actual source 
document.
    ToDo: Part 3: Jim: pg. vii: Part 2 should not have "this document" 
(line 15). It should be moved (or removed entirely) to Part 3 (line 19). - 
Done.
    ToDo: Part 3 (Comment 2): Jim: Combination needs to be added. - Done.
    ToDo: Part 3 (Comment 3): Jim: Note describing why we are not adding 
implementation defined. - Done.
    ToDo: Part 3 (Comment 5): Jim: Draft up a few sentences to add to F.3 
describing how to do the convertFormat operations in C. - Done.

    ToDo: Part 4: Jim: pg. vii: Part 2 should not have "this document" 
(line 15). It should be moved (or removed entirely) to Part 4 (line 19). - 
Done.
    ToDo: Part 4 (Comment 9): Jim: Set the response for this comment to: 
scaled_prodsum and scaled_proddiff functions can have p and q overlap so 
they should not have restrict specified. - Done. Upon discussion with WG14 
we did add restrict.
    ToDo: Part 4: Jim: Missed another missing argument: Page 22 line 13: 
reduc_sumprod last bullet has n,p instead of n,p,q as the arguments. - 
Done.

    ToDo: David: Check for UK call in numbers (or other countries) and 
check with Mike on access need.

  New action items:
    ToDo: Rajan/Fred: Find out what is happening with the LaTeX migration 
in terms of timing.
    ToDo: Rajan: Update liaison words as discussed in the meeting.
    ToDo: Part 5: Evaluation Formats: Jim: Should be "value of 
FLT_EVAL_METHOD".
    ToDo: Part 5: Evaluation Formats: Jim: "Use of other values of width" 
-> "Use of unsupported values of width"
    ToDo: Part 5: Value changing optimizations: Jim: Remove 
FENV_ALLOW_WIDER_INTERMEDIATE_RESULTS and say that the #pragma STDC 
FENV_FLT_EVAL_METHOD width takes care of it.

  Next Meeting:
    December 2nd (Tuesday), 2014, 12:00 EST, 9:00 PDT
    Same teleconference number.
    Note: Future meetings (2015) will be using Rajan's teleconference 
number.

  Discussion:
    Part 1: Published.

    Part 2: Final draft sent to ISO for review. Will come back to Jim for 
final check (still not sent back from ISO).
      Date will need to be set in the macro portion of the text. We will 
need to do the same for parts 3 and 4.

    Part 3: Comment resolution:
      Suggested resolution documents provided in WG14 meeting mailing.
      Draft, assuming all suggested responses are accepted, is ready. We 
can tell the committee that the documents are ready for voting and only 
need document numbers.

    Part 4: Comment resolution:
      Suggested resolution documents provided in WG14 meeting mailing.
      Draft, assuming all suggested responses are accepted, is ready. We 
can tell the committee that the documents are ready for voting and only 
need document numbers.

    Part 5: (Email discussion based on email from Jim today)
      Evaluation formats:
        ToDo: Part 5: Evaluation Formats: Jim: Should be "value of 
FLT_EVAL_METHOD".
        ToDo: Part 5: Evaluation Formats: Jim: "Use of other values of 
width" -> "Use of unsupported values of width"
        Issue #1: OK
        Issue #2: No.
      Value changing optimizations:
        Issue #3: Leave open.
          Points brought up: Consistency with other STDC pragmas, more 
descriptive to use ALLOW/DISALLOW, long name to type.
        Issue #4: Remove/reword text as it is invalid.
          The optimizations can consist of converting division to 
multiplication so it is not just type changing.
        Issue #5: No.
          Usually binary and DFP are in different sections so they can use 
the #pragma for those sections. i.e. They are usually not interspersed.
        Issue #6: Leave separate for now.
          The IEEE standard is explicit about both of these so even though 
FP_CONTRACT covers it we will leave it in.
        Allow wider intermediate results:
          The FENV eval method takes care of this.
          ToDo: Jim: Remove it and say that the #pragma STDC 
FENV_FLT_EVAL_METHOD width takes care of it.
        Issue #7: Keep open.
          Should we say a general rule that more specific pragma's 
override the general ones?
          Perhaps group them or list the interactions?
        Issue #8: Open in modified form.
          The division one is important.
          The question is whether to provide it to give the same syntax 
for everyone or leave it open for implementations to decide including 
potentially incompatible ones.
          Compiler's would probably prefer to have less to implement.
          Users would probably prefer more control.
          List the ones we consider important and list the rest as ones 
considered.
      Reproducible results:
        Must use correctly rounded functions, no wider format evaluation, 
etc. If something else is used, you don't have reproducible results.
        Math functions that are not correctly rounded? Have a separate 
directive for transcendental functions?
        Issue #9: More to talk about next time.
          For which parts:
            All implementations with the same parts?
          Disallow/Diagnose non-reproducible constructs:
            One view is to turn off things that could affect 
reproducibility, other is to diagnose things that may be not reproducible.
            Should be generating reproducible code.
 
Regards,

Rajan Bhakta
z/OS XL C/C++ Compiler Technical Architect
ISO C Standards Representative for Canada
C Compiler Development
Contact: rbhakta at us.ibm.com, Rajan Bhakta/Houston/IBM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20141016/57bcab32/attachment.html