<font size=2 face="sans-serif">2015/02/17, 12:00 EST:</font>
<br><font size=2 face="sans-serif"> <b>Attendees</b>: Rajan, Jim,
Mike, Vincent, Fred, Marius, David, Ian</font>
<br>
<br><font size=2 face="sans-serif"> <b>New agenda items:</b></font>
<br><font size=2 face="sans-serif"> None.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> <b>Sticky action items:</b></font>
<br><font size=2 face="sans-serif"> 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.</font>
<br><font size=2 face="sans-serif"> David: Part 5: SUBSTITUTEXOR
-> SUBSTITUTE_XOR. Pending issue resolution. - Leave open</font>
<br>
<br><font size=2 face="sans-serif"> <b>Last meeting action items:</b></font>
<br><font size=2 face="sans-serif"> Jim: Ask Fred if the next
meeting date is good for him. - Done</font>
<br><font size=2 face="sans-serif"> Jim: Check with David
Keaton on where Part 2 is. - Done</font>
<br><font size=2 face="sans-serif"> David: Write up a proposal
for what the FENV_REPRODUCIBLE pragma means - Not done</font>
<br><font size=2 face="sans-serif"> David: Write up a proposal
for alternate exception handling - Not done</font>
<br>
<br><font size=2 face="sans-serif"> <b>New action items:</b></font>
<br><font size=2 face="sans-serif"> Jim: p4: Line 27: The
STDC pragmas should be FENV_ prefixed</font>
<br><font size=2 face="sans-serif"> Jim: p5: Line 20: x *
y should be x + y</font>
<br><font size=2 face="sans-serif"> Jim: p5: Line 33: x /
y = x * (1 / z) --> x / y = x * (1 / y)</font>
<br><font size=2 face="sans-serif"> Jim: p6: Add a note saying
that the optimizations do not have to be consistent.</font>
<br><font size=2 face="sans-serif"> Jim: Some dash's have
become hyphens throughout the document.</font>
<br><font size=2 face="sans-serif"> Jim: p6: Add a note saying
754 says synthesis where we say contract.</font>
<br><font size=2 face="sans-serif"> 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).</font>
<br><font size=2 face="sans-serif"> David: Write up a small
description of what is required from IEEE for reproducible results and
changes to make it useful and implementable.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> <b>Next Meeting:</b></font>
<br><font size=2 face="sans-serif"> March 17th, 2015, 12:00
EST, 9:00 PDT</font>
<br><font size=2 face="sans-serif"> Same teleconference number.</font>
<br>
<br><font size=2 face="sans-serif"> <b>Discussion:</b></font>
<br><font size=2 face="sans-serif"> Introductions - Vincent
is new to the call.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Part 1: Published.</font>
<br>
<br><font size=2 face="sans-serif"> Part 2: Approved. Still
waiting for edits from ISO for review.</font>
<br>
<br><font size=2 face="sans-serif"> Part 3: USA has balloted
already, international is still open.</font>
<br>
<br><font size=2 face="sans-serif"> Part 4: USA has balloted
already, international is still open.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Part 5:</font>
<br><font size=2 face="sans-serif"> cfp5-notes-20150211.pdf:</font>
<br><font size=2 face="sans-serif"> p vii: Supplementary
attributes at bottom of page: Who is writing it? Open.</font>
<br><font size=2 face="sans-serif"> p2: 5.3:
Don't expect any new identifiers</font>
<br><font size=2 face="sans-serif"> p3: 7.6.1c:
Fred: Undefined behaviour too harsh?</font>
<br><font size=2 face="sans-serif"> Consensus
is that it is appropriate.</font>
<br><font size=2 face="sans-serif"> p3: 7.6.1c:
Fred: Why is zero a valid value? Ex. Intel chips do double rounding on
denorms.</font>
<br><font size=2 face="sans-serif"> It
is possible.</font>
<br><font size=2 face="sans-serif"> *ToDo: Jim:
p4: Line 27: The STDC pragmas should be FENV_ prefixed</font>
<br>
<br><font size=2 face="sans-serif"> 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.</font>
<br><font size=2 face="sans-serif"> Need to
refer to each other to ensure interactions are considered.</font>
<br>
<br><font size=2 face="sans-serif"> *ToDo: Jim:
p5: Line 20: x * y should be x + y</font>
<br><font size=2 face="sans-serif"> *ToDo: Jim:
p5: Line 33: x / y = x * (1 / z) --> x / y = x * (1 / y)</font>
<br><font size=2 face="sans-serif"> 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.</font>
<br><font size=2 face="sans-serif"> *ToDo: Jim:
p6: Add a note saying that the optimizations do not have to be consistent.</font>
<br><font size=2 face="sans-serif"> *ToDo: Jim:
Some dash's have become hyphens throughout the document.</font>
<br>
<br><font size=2 face="sans-serif"> Issue 2:
Keep contract. Can make a note about this issue.</font>
<br>
<br><font size=2 face="sans-serif"> *ToDo: Jim:
p6: Add a note saying 754 says synthesis where we say contract.</font>
<br><font size=2 face="sans-serif"> *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).</font>
<br>
<br><font size=2 face="sans-serif"> 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.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Note: Contract
can be for anything, not just FMA, as long as there is a single rounding.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Reproducible results:</font>
<br><font size=2 face="sans-serif"> David: Is
there anything in C that specifies how to do a+b+c?</font>
<br><font size=2 face="sans-serif"> Yes: Left
to right unless parenthesized.</font>
<br><font size=2 face="sans-serif"> 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.</font>
<br><font size=2 face="sans-serif"> More to
say regarding Complex arithmetic reproducibility.</font>
<br><font size=2 face="sans-serif"> There is
an example in the standard for divide and multiply. Gives requirements
for correctness.</font>
<br><font size=2 face="sans-serif"> The value
changing optimizations and evaluation are handled above.</font>
<br><font size=2 face="sans-serif"> David: The
default should be reproducible results.</font>
<br><font size=2 face="sans-serif"> Jim:
What does this mean?</font>
<br><font size=2 face="sans-serif"> David:
You should have to ask for optimizations that can affect reproducible results.</font>
<br><font size=2 face="sans-serif"> Note
that we can't make existing implementations that are not reproducible by
default fail with this TS.</font>
<br><font size=2 face="sans-serif"> From
the IEEE spec, it must be user selectable to have reproducible results.
i.e. Not required to be default.</font>
<br><font size=2 face="sans-serif"> Required
to warn/diagnose when not reproducible. Ex. Using non-correctly rounded
transcendental functions.</font>
<br><font size=2 face="sans-serif"> Ex.
Using complex may not be reproducible.</font>
<br><font size=2 face="sans-serif"> 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.</font>
<br><font size=2 face="sans-serif"> The large
number of warning messages may not be that much if the non-reproducible
functions are not common in code.</font>
<br><font size=2 face="sans-serif"> 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.</font>
<br><font size=2 face="sans-serif"> *ToDo: David:
Write up a small description of what is required from IEEE for reproducible
results and changes to make it useful and implementable.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Alternate exception
handling:</font>
<br><font size=2 face="sans-serif"> Still to
do.</font>
<br>
<br><font size=2 face="sans-serif">Regards,<br>
<br>
Rajan Bhakta<br>
z/OS XL C/C++ Compiler Technical Architect<br>
ISO C Standards Representative for Canada<br>
C Compiler Development<br>
Contact: rbhakta@us.ibm.com, Rajan Bhakta/Houston/IBM</font>