[Cfp-interest] WG14 IEEE 754-C binding meeting minutes 2015/02/18

[Rajan Bhakta]

2015/02/17, 12:00 EST:
  Attendees: Rajan, Jim, Mike, Vincent, Fred, Marius, David, Ian

  New agenda items:
    None.
 
  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:
    Jim: Ask Fred if the next meeting date is good for him. - Done
    Jim: Check with David Keaton on where Part 2 is. - Done
    David: Write up a proposal for what the FENV_REPRODUCIBLE pragma means 
- Not done
    David: Write up a proposal for alternate exception handling - Not done

  New action items:
    Jim: p4: Line 27: The STDC pragmas should be FENV_ prefixed
    Jim: p5: Line 20: x * y should be x + y
    Jim: p5: Line 33: x / y = x * (1 / z) --> x / y = x * (1 / y)
    Jim: p6: Add a note saying that the optimizations do not have to be 
consistent.
    Jim: Some dash's have become hyphens throughout the document.
    Jim: p6: Add a note saying 754 says synthesis where we say contract.
    Jim: p7: Need example for contract operation conversion. Ex. float a = 
b * c (where b, c can be double's, and allow a single rounding).
    David: Write up a small description of what is required from IEEE for 
reproducible results and changes to make it useful and implementable.
 
  Next Meeting:
    March 17th, 2015, 12:00 EST, 9:00 PDT
    Same teleconference number.

  Discussion:
    Introductions - Vincent is new to the call.
 
    Part 1: Published.

    Part 2: Approved. Still waiting for edits from ISO for review.

    Part 3: USA has balloted already, international is still open.

    Part 4: USA has balloted already, international is still open.
 
    Part 5:
      cfp5-notes-20150211.pdf:
        p vii: Supplementary attributes at bottom of page: Who is writing 
it? Open.
        p2: 5.3: Don't expect any new identifiers
        p3: 7.6.1c: Fred: Undefined behaviour too harsh?
          Consensus is that it is appropriate.
        p3: 7.6.1c: Fred: Why is zero a valid value? Ex. Intel chips do 
double rounding on denorms.
          It is possible.
        *ToDo: Jim: p4: Line 27: The STDC pragmas should be FENV_ prefixed

        Issue 1: Can decouple the optimization pragma from the evaluation 
method pragma. Inter-relations cause complications however. We can add a 
note that -ve evaluation methods can have value changing optimizations.
        Need to refer to each other to ensure interactions are considered.

        *ToDo: Jim: p5: Line 20: x * y should be x + y
        *ToDo: Jim: p5: Line 33: x / y = x * (1 / z) --> x / y = x * (1 / 
y)
        p6: Allow zero: Does it have to be always? We should say it does 
not have to be consistent. Ex. It may occur only sometimes.
        *ToDo: Jim: p6: Add a note saying that the optimizations do not 
have to be consistent.
        *ToDo: Jim: Some dash's have become hyphens throughout the 
document.

        Issue 2: Keep contract. Can make a note about this issue.

        *ToDo: Jim: p6: Add a note saying 754 says synthesis where we say 
contract.
        *ToDo: Jim: p7: Need example for contract operation conversion. 
Ex. float a = b * c (where b, c can be double's, and allow a single 
rounding).

        Issue 3: Obsolesce of the older pragma would result in changing 
the references to that pragma throughout the C standard. We should 
explicitly say they are synonyms. Consensus is to keep both with the note 
about saying they are synonyms.
 
        Note: Contract can be for anything, not just FMA, as long as there 
is a single rounding.
 
      Reproducible results:
        David: Is there anything in C that specifies how to do a+b+c?
        Yes: Left to right unless parenthesized.
        Using the correctly rounded transcendental functions by default 
when you have them. When not correctly rounded by default, this is where a 
lot of time is spent.
        More to say regarding Complex arithmetic reproducibility.
        There is an example in the standard for divide and multiply. Gives 
requirements for correctness.
        The value changing optimizations and evaluation are handled above.
        David: The default should be reproducible results.
          Jim: What does this mean?
          David: You should have to ask for optimizations that can affect 
reproducible results.
          Note that we can't make existing implementations that are not 
reproducible by default fail with this TS.
          From the IEEE spec, it must be user selectable to have 
reproducible results. i.e. Not required to be default.
        Required to warn/diagnose when not reproducible. Ex. Using 
non-correctly rounded transcendental functions.
          Ex. Using complex may not be reproducible.
        The requirement that there must be a way to ensure reproducible 
behaviour even for other CU's linked in and other library functions will 
be hard to meet for some environments.
        The large number of warning messages may not be that much if the 
non-reproducible functions are not common in code.
        Fred: Casts are being ignored for floats to integers 'float a = 
(float)DBL_MIN;' for every compiler I've tested. It is very hard to get 
reproducible results as some things are done at translation time and 
others are done at run-time.
        *ToDo: David: Write up a small description of what is required 
from IEEE for reproducible results and changes to make it useful and 
implementable.
 
      Alternate exception handling:
        Still to do.

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/20150218/aa8ac6a8/attachment.html