[Cfp-interest] WG14 meeting results

[Rajan Bhakta]

Hello,

Here are the results from the WG14 meeting for items relating to our 
group.
These are rough notes, so please let me know if anyone needs 
clarification.

Proposals:

N2117: Part 3 (extended & interchange types)
  Comments:
    Concern about the lack of implementation experience.
    Any group demanding these features?
    Not comfortable to go with this yet.
  Result: Put in SD3.

N2118: Part 4a (math functions)
  Comments:
    Concerns about these names being in the user namespace, especially 
with C++ due to the reserved names rules.
      With no WANT macro, the functions still can be used by a user in 
code and by other library functions.
  Result: Put in SD3.

N2119: Part 4b (reduction functions)
  Comments:
    Same concern with the namespace.
      Can reserve these names in C17 to avoid this issue?
  Result: Put in SD3.

N2120: Part 5a (evaluation pragmas)
  Comments:
    Blaine: All part 5 should be together, not separate.
  Result: Put in SD3.

N2121: Part 5b (optimization pragmas)
  Comments:
    Nothing new.
  Result: Put in SD3.

N2122: Part 5c (reproducible results)
  Comments:
    Nothing new.
  Result: Put in SD3.

N2123: Part 5d (alternate exception handling)
  Comments:
    Non ignorable pragma.
      Can be tweaked to avoid this. Ex. FEDIVZERO(expression)
  Straw poll: Do we want to add N2123 to SD3? 6/8/4
  Straw poll: Do we want something along the lines of N2123 in SD3? 12/2/4
  Result: Direction to do something like this, but not this.
 
N2124:
  Comments:
    Note issue of bits in hardware for rounding modes may not be enough.
  Result: Put in SD3.

N2125:
  Comments:
    DDR1: DR12. Accepted.
    DDR2: DR13. Accepted.
      On the edge of invention, not really a DR. But will accept it as a 
DR since it is a TS.
    DDR3: DR14. Accepted.
      Parenthetical makes it seem less important. Perhaps remove them?
  Result: From now on, just create them as DR's and not draft DR's.

N2128: Default rounding mode
  Comments:
    Straw poll: Add to SD3: 4/7/7
  Result: Not adding to SD3.

C DR's:
  DR500: Move to review.
  DR501:
    Comments:
      Fred: double_t is a floating type that allows this.
      Why is it not possible to have DECIMAL_DIG be the largest floating 
type?
    Result: Should we obsolesce DECIMAL_DIG? 6/0/7 (Yes)

Floating point DR's:
  DR1: Move to closed.
  DR2: Move to closed.
  DR3: Move to closed.
  DR4: Move to closed.
 
  DR5: Move to review.
  DR6: Move to review.
  DR7: Move to review.
  DR8: Move to review.
  DR9: Leave in open, taking N2127 as the second change.
  DR10: Move to review.
  DR11: Add the example in N2126 into the TS.
    Concern: Precision now means something different based on the 
datatype.
    Which of matching %g or matching %a with other datatypes where the 
number after the decimal point (the precision) should be used instead of 
significant digits (as with %g).

Tasks that the group can take on/continue:
  1. Write and address DRs against the TS as needed, and submit them to WG 
14.
  2. Propose to WG 14 incorporating the TS (or parts of it) into C2x.
  3. Support accepted proposals through the C2x standardization process.
  4. Write proposals for a C binding for the new features in IEEE 
754-2018, and followup with WG 14. This is a compatible change to 754, 
with only a very few new (recommended) features, which if addressed by our 
current efforts would give us another 10 or so years for FP standard 
support.
  5. Revise parts of the TS that are not incorporated into C2x to be based 
on C2x.
  Result: Keep the group going. Do everything listed above.

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/20170406/f18f405c/attachment.html