<font size=2 face="sans-serif"><b>Attendees</b>: Rajan, Blaine, Jim, Mike,
Fred, Vincent, David, Ian</font>
<br>
<br><font size=2 face="sans-serif"><b>New agenda items</b>:</font>
<br><font size=2 face="sans-serif"> Email discussions to be brought
in.</font>
<br>
<br><font size=2 face="sans-serif"><b>Last meeting action items</b>:</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-diff-20150211-20150309.pdf:
p9: Line 10: Note that we need to make sure functions with two or more
arguments (since the order of evaluation of them is not fixed) is handled.
- Listed as unspecified behaviour in IEEE. In our spec we say in Annex
J the program has to deal with it. Jim to send an email regarding this.
- Keep open</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-diff-20150211-20150309.pdf:
p9: Line 37: Look into tightening the underflow and inexact part. - Still
open. - IEEE says the program can't depend on inexact or underflow. David:
May be due to before or after rounding. David: With underflow, flags and
traps are not the same due to exact underflow. - Keep open</font>
<br>
<br><font size=2 face="sans-serif"> Ian: Talk to Michael Wong
and Lowell regarding proposing this IEEE-754: 2008 binding to C++ as well
- Keep open</font>
<br><font size=2 face="sans-serif"> Rajan, Jim: Talk to David
Keaton regarding our intent for putting the essentials of parts 1 and 2
(not necessarily exact match) of this TS into the next C Standard. Need
to look at reflector message 13739. - Keep open</font>
<br><font size=2 face="sans-serif"> Jim: Part 5: Write up
the delayed goto transformation to prolog/epilog code. - Done</font>
<br><font size=2 face="sans-serif"> Jim: Part 5: Write up
text to allow 'break's to still cause the epilog code to be executed for
delayed goto's. - Done</font>
<br><font size=2 face="sans-serif"> Jim: Part 5: Add in examples
of ASAP and Delayed Goto pragma's in the same block and in different orders.
- An example with two delayed Goto's and text re ASAP was added. - Keep
open</font>
<br><font size=2 face="sans-serif"> Jim: Part 5: Add in a
new issue - Is it worth adding expression evaluation methods that widen
the library functions as well as the operators (that is already there)?
- Email sent to discuss this yesterday - Keep open</font>
<br><font size=2 face="sans-serif"> David: Part 5: Provide
a mechanism (a new #pragma?) to allow implementations to possibly not propagate
constant modes (rounding, exceptions). - Email sent out (May 20th,
2015) - Keep open</font>
<br>
<br><font size=2 face="sans-serif"><b>New action items</b>:</font>
<br><font size=2 face="sans-serif"> Blaine: Send out a DR
process document so we can use that for Parts 1-4.</font>
<br><font size=2 face="sans-serif"> Rajan: Create an outline
of features in parts 1 and 2.</font>
<br><font size=2 face="sans-serif"> Jim: Update the wiki to
put in links to the test suites (from Mike) and possibly compiler manuals
that address these parts.</font>
<br><font size=2 face="sans-serif"> Fred: Find out the expiry
date for an ISO document.</font>
<br><font size=2 face="sans-serif"> Jim: Page 1: Fill in dates
for parts 3 and 4.</font>
<br><font size=2 face="sans-serif"> Jim: Page 3 and 4: Make
the changes as proposed in the email on 2015/06/10 by Jim</font>
<br><font size=2 face="sans-serif"> All: Do the FENV_ALLOW_*
pragmas apply to complex types?</font>
<br><font size=2 face="sans-serif"> Jim: Add a conformance
macro for alternate exception handling.</font>
<br><font size=2 face="sans-serif"> Jim: Word the goto description
better to disallow jumping to a label for an exception that did not happen.</font>
<br>
<br><font size=2 face="sans-serif"><b>Next Meeting</b>:</font>
<br><font size=2 face="sans-serif"> July 7th, 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"> Part 1: Published.</font>
<br>
<br><font size=2 face="sans-serif"> Part 2: 2nd edition has
been published.</font>
<br>
<br><font size=2 face="sans-serif"> Part 3: Final drafts have
been sent to INCITS and should be sent to ISO soon. Estimating July 1st
publication.</font>
<br>
<br><font size=2 face="sans-serif"> Part 4: Final drafts have
been sent to INCITS and should be sent to ISO soon. Estimating July 1st
publication.</font>
<br>
<br><font size=2 face="sans-serif"> *ToDo: Blaine: Send out
a DR process document so we can use that for Parts 1-4.</font>
<br>
<br><font size=2 face="sans-serif"> Incorporating the TS into
the C standard (see Joseph Myers email on 2015/05/21):</font>
<br><font size=2 face="sans-serif"> IBM doesn't have
Part 2 complete (no constant rounding modes for example).</font>
<br><font size=2 face="sans-serif"> GCC is mostly library
for part 1.</font>
<br><font size=2 face="sans-serif"> We need an inventory
of the features in part 1 and 2 and have implementers check off what they
have.</font>
<br><font size=2 face="sans-serif"> *ToDo: Rajan: Create
an outline of features in parts 1 and 2.</font>
<br><font size=2 face="sans-serif"> Is there a comprehensive
test suite for this?</font>
<br><font size=2 face="sans-serif"> Mike has
some test suites available on his website.</font>
<br><font size=2 face="sans-serif"> Fred has
coverage for most of it.</font>
<br><font size=2 face="sans-serif"> *ToDo: Jim:
Update the wiki to put in links to the test suites (from Mike) and possibly
compiler manuals that address these parts.</font>
<br>
<br><font size=2 face="sans-serif"> Status of IEEE 754-2008:</font>
<br><font size=2 face="sans-serif"> Upcoming for renewal.</font>
<br><font size=2 face="sans-serif"> Use Mike's errata
sheet and have that be a revision.</font>
<br><font size=2 face="sans-serif"> Mike: The items
don't justify the full process.</font>
<br><font size=2 face="sans-serif"> Ian: Add in relative
error for an add for example in a portable way. Perhaps a correctly rounded
dot product, complete arithmetic, exact dot product, etc. 0 * Inf if Inf
came from an overflow, should give 0 instead of NaN.</font>
<br><font size=2 face="sans-serif"> David: Re:
Inf * 0: Not used much (already implemented on sparc)</font>
<br><font size=2 face="sans-serif"> Still looking for
someone to chair this group.</font>
<br><font size=2 face="sans-serif"> Expiring is unlikely.
A number of people have volunteered to be a part of the committee.</font>
<br><font size=2 face="sans-serif"> *ToDo: Fred: What
is the expiry date for an ISO document?</font>
<br>
<br><font size=2 face="sans-serif"> Part 5: Various emails
+ </font><a href="http://wiki.edg.com/twiki/pub/CFP/WebHome/cfp5-20150608.pdf"><font size=2 color=blue face="sans-serif">http://wiki.edg.com/twiki/pub/CFP/WebHome/cfp5-20150608.pdf</font></a>
<br><font size=2 face="sans-serif"> *ToDo: Jim: Page
1: Fill in dates for parts 3 and 4.</font>
<br><font size=2 face="sans-serif"> Re email on 2015/06/10
by Jim: action item on expression evaluation methods and math functions</font>
<br><font size=2 face="sans-serif"> The eval
method can change value now (if it sees a pragma).</font>
<br><font size=2 face="sans-serif"> Consensus
is to adopt the changes as proposed in the email.</font>
<br><font size=2 face="sans-serif"> *ToDo: Jim:
Page 3 and 4: Make the changes as proposed in the email on 2015/06/10 by
Jim</font>
<br><font size=2 face="sans-serif"> Page 7:</font>
<br><font size=2 face="sans-serif"> Should there
be a shorthand for the list of operations?</font>
<br><font size=2 face="sans-serif"> Doing it
would be a large editorial change and likely not easier to read by anyone.</font>
<br><font size=2 face="sans-serif"> Fred's email: Do
the pragma's apply to complex types?</font>
<br><font size=2 face="sans-serif"> For complex
types at IBM, they use FMA so if the pragma's apply this would change the
behaviour.</font>
<br><font size=2 face="sans-serif"> For complex,
multiple and divide there is no requirement they are commutative.</font>
<br><font size=2 face="sans-serif"> *ToDo: All:
Do the FENV_ALLOW_* pragmas apply to complex types?</font>
<br><font size=2 face="sans-serif"> We should
make this a suggestion rather than require it.</font>
<br><font size=2 face="sans-serif"> Note that
the real part vs the imaginary part could cause different exceptions. Ex.
complex divide gives underflow and overflow both.</font>
<br><font size=2 face="sans-serif"> IEEE does
not cover complex operations other than add and subtract.</font>
<br><font size=2 face="sans-serif"> Ex.
Not required to produce most exceptions for complex operations.</font>
<br><font size=2 face="sans-serif"> David's email:
2015/05/20:</font>
<br><font size=2 face="sans-serif"> Keep the
issue open.</font>
<br><font size=2 face="sans-serif"> Should alternate
exception handling be moved to a new part, part 6?</font>
<br><font size=2 face="sans-serif"> The original
reason for having them together was to have the same mechanism for both,
but that has been settled.</font>
<br><font size=2 face="sans-serif"> Another
option is to have another conformance macro for exception handling.</font>
<br><font size=2 face="sans-serif"> Leave this
open?</font>
<br><font size=2 face="sans-serif"> Having a
conformance macro allows more implementation choice and increases the odds
of acceptance.</font>
<br><font size=2 face="sans-serif"> *ToDo: Jim:
Add a conformance macro for alternate exception handling.</font>
<br><font size=2 face="sans-serif"> #pragma vs try/catch:</font>
<br><font size=2 face="sans-serif"> #pragma
seemed the least disliked option</font>
<br><font size=2 face="sans-serif"> Some people
felt there was strong sentiment in WG14 against keyword/syntax changes,
but not all</font>
<br><font size=2 face="sans-serif"> Page 11: Optional_flag:
Should this be FLAG(s)_UNSPECIFIED instead? OPTIONAL_FLAG seems to be confusing
for a naive user.</font>
<br><font size=2 face="sans-serif"> This means
that IEEE specified flags set for an operation need not be set.</font>
<br><font size=2 face="sans-serif"> Note that
this could mean you could set a flag where not specified. This was not
the intent.</font>
<br><font size=2 face="sans-serif"> Perhaps
OPTIONAL_FLAG -> FLAG_OPTIONAL</font>
<br><font size=2 face="sans-serif"> Need to
keep the relationship between NO_FLAG and OPTIONAL_FLAG</font>
<br><font size=2 face="sans-serif"> Suggestion:
NO_FLAG -> NO_FLAGS, OPTIONAL_FLAG -> ELIDABLE_FLAGS (or perhaps
without the S's)</font>
<br><font size=2 face="sans-serif"> Consensus
is to keep as is for now.</font>
<br><font size=2 face="sans-serif"> Page 12: goto:
The label/goto has to be linked to only the ones with exceptions that has
happened (not to ones that have not happened).</font>
<br><font size=2 face="sans-serif"> *ToDo: Jim:
Word the goto description better to disallow jumping to a label for an
exception that did not happen.</font>
<br><font size=2 face="sans-serif"> The descriptions
here relate to the goto's with the same associated block.</font>
<br><font size=2 face="sans-serif"> We need
general clarity on goto's in general. This applies to the static rounding
modes as well.</font>
<br><font size=2 face="sans-serif"> *ToDo: Blaine:
Send an email to continue the goto discussion and issues.</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>