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

Thu Oct 10 10:56:06 PDT 2013


2013/10/10, 12:00 EST:
  Attendees: Jim, David, Rajan, Fred, Mike, Ian, Marius

  Old action items:
    Jim: GB-JWT comments: Update the response column to the result of our
discussion and make it our teleconference group suggested responses. - Done
    Jim: JWT comments: Submit them as "Editor's comments" with "Study group
recommendations" with "Agree" in the last column. - Done
    Jim: Talk to John to see if we should post a draft with the changes
we've agreed to so far. - Done - Answered yes.

  Next Meeting:
    November 13th, 2013, 12:00 EST, 9:00 PDT - Wednesday
    Same teleconference number.

  New action items:
    Jim: Part 2: Paragraph 12 should have (+, -, * or /) -> (+, -, * and /)
    Jim: Part 2: Page 8: Line 1: "are distinct types from float" -> "are
distinct from the types
    Jim: Part 2: Page 32: The - sign seems to be in a different font and
seems high. Try and make it look better.
    Jim: Part 2: Page 46: Change to split the table above into two 4 line
chunks and use the individual rules per chunk.
    Jim: Part 2: Binding DFP applicable clauses in Annex F tighter to C11.
Ex. Saying something like "An implementation that defines
__STDC_IEC_559_DFP__ shall conform to the specifications in clauses ... in
this annex"
    Jim: Look into using the Wiki as a backup for the documents in Word
format.
    All: Review Part 3. Comments via email.
    All: Let Jim know of any changes to part 2 as soon as possible.

  Fall 2013 WG14 meeting:
    Part 1: Went over both spreadsheets of comments, WG14 agreed to all
comments.
      Next step is to provide draft with all the changes and have a WG14 3
person review group review the changes.
      The resulting draft will go to DTS ballot (last step for a Technical
Specification for publication).
    Part 2: Jim gave a presentation on the main changes. No serious
concerns raised.
      WG14 agreed to move Part 2 to PDTS ballot (first ISO ballot). See
Jim's email for steps on that.
    Part 3: Jim gave a presentation on the main changes. No serious
concerns raised. They were satisfied with the changes to the non-arithmetic
types (main point of contention in the last meeting).
      Next step is to have an updated draft in the next WG14 meeting to
propose to move towards PDTS (first ISO ballot).

    A long email message was sent to John Benito from Hungary by Szabolcs
Nagy.
      Jim, Rajan, Fred worked on them during the meeting.
      One of the items was related to part 1 (discussed later).
    An email from Joseph Myers regarding the GB comment responses.
      Did not result in changes to Part 1.

  Part 1 (http://wiki.edg.com/twiki/pub/CFP/WebHome/n1774.pdf):
    Jim has submitted the draft with all changes to John Benito, who is
still on vacation. Still looking for when the review committee will meet.
    The Hungary email had some misunderstandings, some that were good
comments which could be DR's.
    Annex F allows wider arguments, results and operations which is not
what IEC 60559 specifies.
    Paragraphs 11 and 12 on page 12 in n1774 (front page of CFP wiki) are
designed to address this.
      *AI* Paragraph 12 should have (+, -, * or /) -> (+, -, * and /)
      These paragraphs make sure we have a binding to the IEC 60559
operations even with wider evaluation.

  Part 2 (http://wiki.edg.com/twiki/pub/CFP/WebHome/cfp2-20131010.pdf):
    Changes from the October 4th draft based on Fred's comments. No other
comments from other members.
    Fred: Didn't like my comments on the forward?
    Jim: Based on the ISO template so I don't want to change it unless ISO
tells me.
    Page 3 (5.3): No comments.
      Line 21: No comments.
      Line 28: No comments.
    Page 7: No comments.
    Page 8: Line 1: No comments for first change. *AI* "are distinct types
from float" -> "are distinct from the types float"
      Line 16: No comments.
    Page 9: Line 5: No comments.
    Page 10: Line 6: No comments.
    Page 14: Due to part 1 changes adding paragraphs 11 and 12. No
comments.
    Page 31: No comments.
    Page 32: The - sign seems to be in a different font and seems high.
*AI* Jim to try and make it look better.
    Page 36: No comments.
    Page 37: No comments.
    Page 39: No comments.
    Page 40: No comments.
    Page 42: No comments.
    Page 44: No comments.
    Page 45: No comments.
    Page 46: Mike: Solves the problem. An alternative change is to split
the table above into two 4 line chunks and use the individual rules per
chunk. This avoids the implicit ordering of rules.
      Ian: The sentences now are in opposite order to the functions.
      Jim: The d is not a prefix in d32.
      Mike: Another fix is to say "the prefixes are d32, d64, f, d".
      *AI* Do Mikes first alternative change.
    Page 47: No comments.

    Freds comments (email on 2013/10/07, titled Re: moving Part 2 forward):
      12.3 (accuracy): Jim: The connection to annex F is in Clause 2.
        The issue is we haven't made any changes to C11 that link the DFP
specifications that rely on Annex F to C11.
        Jim: Should we move text from this into Annex F clause 1 saying
something like "An implementation that defines __STDC_IEC_559_DFP__ shall
conform to the specifications in clauses ... in this annex"?
        *AI* Jim: Make the changes along the lines above to bind Part 2
tighter to C11 with respect to following Annex F clauses.
      Internal representations: Jim: Left as a DR or an editorial change
for Larry from WG14 meeting.

    The goal is to have the ballot done so the resolution can be done in
the April 2014 WG14 meeting.

  Part 3 (http://wiki.edg.com/twiki/pub/CFP/WebHome/n1758.pdf):
    Jim showed the slide set shown in the Fall 2013 WG14 meeting as an
overview of changes
(http://wiki.edg.com/twiki/pub/CFP/WebHome/TS18661-3_slides.pptx).
      Example 2: If you also had 80-bits, _Float32x could be 64, 80 or 128,
while _Float64x could be 80, 128 as long as it was at least as wide as
_Float32x.
      Fred: Example 3: Are you are missing _Decimal32x?
      Jim: No, you only need extended on basic types which IEEE does not
have _Decimal32 there.
      Ian: Example 1: _Float24 possible? Ex. _Float16x?
      Jim: No, since _Float16 is not a basic type and neither is _Float24.
    One of the comments from Nagy was regarding the parts not talking about
expression evaluation methods.
      Jim: We should look at doing it even though it seems to naturally fit
in part 5.
        An alternative is to say it is entirely implementation defined how
it fits in.
        Rajan: Prefer saying implementation defined and/or that Part 5 will
have a recommended specification for this.
      Jim: We should think through it now on how to handle this.

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/20131010/cfffa3e3/attachment.html