<font size=2 face="sans-serif">2014/04/15, 12:00 EST:</font>
<br><font size=2 face="sans-serif"> <b>Attendees</b>: Jim, Rajan,
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>Old action items</b>:</font>
<br><font size=2 face="sans-serif"> Jim: Part 4: Page 6: Talk
to Fred to see if he is OK with the errors - Done</font>
<br><font size=2 face="sans-serif"> Rajan: Ask WG14 why pole
errors are specified the way they are in the C meeting - Done</font>
<br><font size=2 face="sans-serif"> Everyone: Send Rajan available
times for April 7-11th and contact information - Done</font>
<br><font size=2 face="sans-serif"> David: Making the first
draft of part 5 - Done, keep open</font>
<br><font size=2 face="sans-serif"> Jim: Send David the C
floating point pragma scope/effects - Done</font>
<br>
<br><font size=2 face="sans-serif"> <b>Next Meeting</b>:</font>
<br><font size=2 face="sans-serif"> May 13th, 2014, 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>New action items</b>:</font>
<br><font size=2 face="sans-serif"> Jim: Work with John and
David Keaton to get the parts 2, 3 and 4 issued for ballot.</font>
<br><font size=2 face="sans-serif"> Jim: Part 4: Divide it
up and assign (or open to assign) reviewers to parts of the document.</font>
<br><font size=2 face="sans-serif"> Jim: Part 4: Give the
document to Joseph and ask if he has any issues with it.</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.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> <b>Discussion</b>:</font>
<br><font size=2 face="sans-serif"> WG14 meeting summary:</font>
<br><font size=2 face="sans-serif"> Pole errors: Not
required to support them (optional feature).</font>
<br><font size=2 face="sans-serif"> Part 1 sent out
for publish.</font>
<br><font size=2 face="sans-serif"> No comments on
part 2. Ready for DTS ballot.</font>
<br><font size=2 face="sans-serif"> No comments on
part 3.</font>
<br><font size=2 face="sans-serif"> WG14 is
good with it going out for PDTS ballot without requiring a 90 day review.</font>
<br><font size=2 face="sans-serif"> Comments on part
4:</font>
<br><font size=2 face="sans-serif"> The new
tanpi, asinpi, acospi should not be a part of the spec and if IEEE does
not specify it then we should not either.</font>
<br><font size=2 face="sans-serif"> Blaine:
Call out the missing functions as additions but not part of the IEEE spec</font>
<br><font size=2 face="sans-serif"> John Benito:
Don't add the functions if not required by IEEE</font>
<br><font size=2 face="sans-serif"> Missing
functions straw poll: Should we keep the new functions added (tanpi, asinpi,
acospi).</font>
<br><font size=2 face="sans-serif"> For/Against/Abstain:
11/4/0</font>
<br><font size=2 face="sans-serif"> WG14 is
good with it going out for PDTS ballot without requiring a 90 day review.</font>
<br><font size=2 face="sans-serif"> Comments on part
5:</font>
<br><font size=2 face="sans-serif"> Question
from committee: Are we still having a part 5?</font>
<br><font size=2 face="sans-serif"> Answer given:
Yes. We will. We are working on it now.</font>
<br><font size=2 face="sans-serif"> DR441: n1730/n1804:
Floating point issues in C11: Weak agree. No Forward p8. Change proposed
committee response to F.2 instead of F.3 (second last bullet). Leave in
open.</font>
<br><font size=2 face="sans-serif"> DR442: n1730/n1804:
Floating point issues in C11: Weak agree. The larger issue given in n1804
is handled by DR441. i.e. Annex F takes precedence and there is no issue.
Leave in open.</font>
<br><font size=2 face="sans-serif"> DR443: n1730/n1804:
Floating point issues in C11: What is the effect of this? Not a defect.
Leave in open with this new response.</font>
<br><font size=2 face="sans-serif"> Conversion from
GROFF to LaTeX for the C standard source is under discussion as being open
for bidding to do the conversion.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Jim: Cut'n'paste to Word
of C11 and has put in part 1. Working on part 2 now. Problems with footnotes
and tables in general.</font>
<br><font size=2 face="sans-serif"> An issue with a
footnote indicator disappearing but the footnote staying present.</font>
<br><font size=2 face="sans-serif"> For part 2 there
is a small editorial change needed.</font>
<br><font size=2 face="sans-serif"> Would like a few
days to put in Part 3 to ensure that there is not anything missing.</font>
<br><font size=2 face="sans-serif"> Bullets get out
of order sometimes.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Part 1: Waiting for publication.</font>
<br><font size=2 face="sans-serif"> No comments.</font>
<br><font size=2 face="sans-serif"> Sent to ITTF for
publication.</font>
<br>
<br><font size=2 face="sans-serif"> Part 2: Will be out for
second ISO ballot (DTS).</font>
<br><font size=2 face="sans-serif"> One comment on
PDTS has been handled.</font>
<br>
<br><font size=2 face="sans-serif"> Part 3: (</font><a href=http://wiki.edg.com/twiki/pub/CFP/WebHome/n1796.pdf><font size=2 face="sans-serif">http://wiki.edg.com/twiki/pub/CFP/WebHome/n1796.pdf</font></a><font size=2 face="sans-serif">)</font>
<br><font size=2 face="sans-serif"> PDTS ballot expected
to be issued.</font>
<br><font size=2 face="sans-serif"> Jim needs a few
days to check his merge into C11 to make sure everything is good.</font>
<br>
<br><font size=2 face="sans-serif"> Part 4: (</font><a href=http://wiki.edg.com/twiki/pub/CFP/WebHome/n1797.pdf><font size=2 face="sans-serif">http://wiki.edg.com/twiki/pub/CFP/WebHome/n1797.pdf</font></a><font size=2 face="sans-serif">)</font>
<br><font size=2 face="sans-serif"> PDTS ballot expected
to be issued.</font>
<br><font size=2 face="sans-serif"> We should look
at it before submitting it for PDTS.</font>
<br><font size=2 face="sans-serif"> Was posted in the
IEEE reflector.</font>
<br><font size=2 face="sans-serif"> *Jim: Part 4: Divide
it up and assign (or open to assign) reviewers to parts of the document.</font>
<br><font size=2 face="sans-serif"> *Jim: Part 4: Give
the document to Joseph and ask if he has any issues with it.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Part 5: (Email from David
sent 2014/04/14)</font>
<br><font size=2 face="sans-serif"> Using a pragma
to affect a block is a good idea since it follows what we've already done.</font>
<br><font size=2 face="sans-serif"> Note: We could
generalize the structured block to allow exits in between (not only at
the end).</font>
<br><font size=2 face="sans-serif"> Block: Compound
statements is what is described in C and can be used.</font>
<br><font size=2 face="sans-serif"> The other pragmas
can be file scope and block scope. We should allow that for these as well.</font>
<br><font size=2 face="sans-serif"> Ian: We might want
to see how this would be handled in C++ as well in a way compatible with
C.</font>
<br><font size=2 face="sans-serif"> C++ is out of scope,
so we will not consider it now.</font>
<br><font size=2 face="sans-serif"> Does underflow
belong in this list?</font>
<br><font size=2 face="sans-serif"> It is an
exception.</font>
<br><font size=2 face="sans-serif"> Note: abrupt
only applies to underflow so the parameters are not orthogonal.</font>
<br><font size=2 face="sans-serif"> We need controls
for value changing optimizations (like FP_CONTRACT).</font>
<br><font size=2 face="sans-serif"> Difference/tension
between programmer intent and debugging intents.</font>
<br><font size=2 face="sans-serif"> #pragma syntax:</font>
<br><font size=2 face="sans-serif"> Change "fpe"
to "FENV_EXCEPT".</font>
<br><font size=2 face="sans-serif"> Change ";"
to ",".</font>
<br><font size=2 face="sans-serif"> Inlining must not
effect the specified behaviour. It should work the same way whether inlined
or not.</font>
<br><font size=2 face="sans-serif"> Library functions:</font>
<br><font size=2 face="sans-serif"> Do the same
as FENV_ROUND pragma: List the functions that are effected if there is
no macro suppression.</font>
<br><font size=2 face="sans-serif"> Since we
implement some of the IEEE operations as library functions we have to do
the same here.</font>
<br><font size=2 face="sans-serif"> Without
dynamic modes it is hard to do.</font>
<br><font size=2 face="sans-serif"> Large number
of combinations here (different from the rounding modes).</font>
<br><font size=2 face="sans-serif"> Dynamic traps are
available at the system level and the compiler deals with it.</font>
<br><font size=2 face="sans-serif"> Link time inlining
may be an issue for some implementations.</font>
<br><font size=2 face="sans-serif"> Immediate and delayed:
ASAP instead of Immediate?</font>
<br><font size=2 face="sans-serif"> Could have abort_asap
and abort_delayed with defaults perhaps.</font>
<br><font size=2 face="sans-serif"> Computed goto,
missing label issues.</font>
<br><font size=2 face="sans-serif"> Can use
a pragma to define a label in a different namespace than normal labels.</font>
<br><font size=2 face="sans-serif"> Can also
make the missing labels undefined.</font>
<br><font size=2 face="sans-serif"> Note scope
issues apply to which label type we choose.</font>
<br><font size=2 face="sans-serif"> Use the C labels
for now and make a note that you can have a separate namespace.</font>
<br><font size=2 face="sans-serif"> Jim: Can we use
function names instead?</font>
<br><font size=2 face="sans-serif"> David: Where would
it return to? Don't want to reinvent setjmp/longjmp.</font>
<br><font size=2 face="sans-serif"> Ignore functions
for now. IEEE talks about goto and abort but not functions.</font>
<br><font size=2 face="sans-serif"> We could have a
_Noreturn function.</font>
<br><font size=2 face="sans-serif"> *David: Part 5:
Complete spec with the full syntax dealing with scope and sub-exceptions.
Include a discussion document with reasons choices and alternatives.</font>
<br><font size=2 face="sans-serif"> Resuming alternate
exception handling should fit in as well.</font>
<br><font size=2 face="sans-serif"> Optimization stuff
should fit in the same framework.</font>
<br><font size=2 face="sans-serif"> David: Preferred
width: Comes under the category of optimizations.</font>
<br><font size=2 face="sans-serif"> Jim: Wasn't intended
to. It should be totally predictable.</font>
<br><font size=2 face="sans-serif"> David will handle
exceptions now, and get to the other ones later.</font>
<br><font size=2 face="sans-serif"> Which parts will
be optional for part 5 (beyond the entire part being optional)?</font>
<br><font size=2 face="sans-serif"> </font>
<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>