<font size=2 face="sans-serif">2014/10/16, 12:00 EST:</font>
<br><font size=2 face="sans-serif"> <b>Attendees</b>: Rajan, Jim,
David, Fred, Ian</font>
<br>
<br><font size=2 face="sans-serif"><b> New agenda items:</b></font>
<br><font size=2 face="sans-serif"> WG14 liaison reporting
- Rajan and Fred going (See part 5)</font>
<br><font size=2 face="sans-serif"> No new documents
to present.</font>
<br><font size=2 face="sans-serif"> If the C standard
is moved to Latex, we have a chance at applying the changes to C11.</font>
<br><font size=2 face="sans-serif"> *ToDo: Rajan/Fred:
Find out what is happening with the LaTeX migration in terms of timing.</font>
<br>
<br><font size=2 face="sans-serif"> New words for liaison
reporting:</font>
<br><font size=2 face="sans-serif"> Parts 3
and 4 are ready for final ballot pending the resolution of the comments
received in the PDTS as decided upon in this meeting.</font>
<br><font size=2 face="sans-serif"> Part 5 is
proceeding using the original #pragma syntax plan because there is no approval
for any of the alternatives proposed. See paper n1841 for this discussion.</font>
<br><font size=2 face="sans-serif"> The
other aspects of Part 5 are being discussed as well.</font>
<br>
<br><font size=2 face="sans-serif"> Part 5 email discussion
(See part 5)</font>
<br>
<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"> ToDo: Part 3: Jim: Formatting
to accurately reflect source document. - Not done. Close it anyways since
it is not present in the actual source document.</font>
<br><font size=2 face="sans-serif"> ToDo: Part 3: Jim: pg.
vii: Part 2 should not have "this document" (line 15). It should
be moved (or removed entirely) to Part 3 (line 19). - Done.</font>
<br><font size=2 face="sans-serif"> ToDo: Part 3 (Comment
2): Jim: Combination needs to be added. - Done.</font>
<br><font size=2 face="sans-serif"> ToDo: Part 3 (Comment
3): Jim: Note describing why we are not adding implementation defined.
- Done.</font>
<br><font size=2 face="sans-serif"> ToDo: Part 3 (Comment
5): Jim: Draft up a few sentences to add to F.3 describing how to do the
convertFormat operations in C. - Done.</font>
<br>
<br><font size=2 face="sans-serif"> ToDo: Part 4: Jim: pg.
vii: Part 2 should not have "this document" (line 15). It should
be moved (or removed entirely) to Part 4 (line 19). - Done.</font>
<br><font size=2 face="sans-serif"> ToDo: Part 4 (Comment
9): Jim: Set the response for this comment to: scaled_prodsum and scaled_proddiff
functions can have p and q overlap so they should not have restrict specified.
- Done. Upon discussion with WG14 we did add restrict.</font>
<br><font size=2 face="sans-serif"> ToDo: Part 4: Jim: Missed
another missing argument: Page 22 line 13: reduc_sumprod last bullet has
n,p instead of n,p,q as the arguments. - Done.</font>
<br>
<br><font size=2 face="sans-serif"> ToDo: David: Check for
UK call in numbers (or other countries) and check with Mike on access need.</font>
<br>
<br><font size=2 face="sans-serif"><b> New action items:</b></font>
<br><font size=2 face="sans-serif"> ToDo: Rajan/Fred: Find
out what is happening with the LaTeX migration in terms of timing.</font>
<br><font size=2 face="sans-serif"> ToDo: Rajan: Update liaison
words as discussed in the meeting.</font>
<br><font size=2 face="sans-serif"> ToDo: Part 5: Evaluation
Formats: Jim: Should be "value of FLT_EVAL_METHOD".</font>
<br><font size=2 face="sans-serif"> ToDo: Part 5: Evaluation
Formats: Jim: "Use of other values of width" -> "Use
of unsupported values of width"</font>
<br><font size=2 face="sans-serif"> ToDo: Part 5: Value changing
optimizations: Jim: Remove FENV_ALLOW_WIDER_INTERMEDIATE_RESULTS and say
that the #pragma STDC FENV_FLT_EVAL_METHOD width takes care of it.</font>
<br>
<br><font size=2 face="sans-serif"><b> Next Meeting:</b></font>
<br><font size=2 face="sans-serif"> December 2nd (Tuesday),
2014, 12:00 EST, 9:00 PDT</font>
<br><font size=2 face="sans-serif"> Same teleconference number.</font>
<br><font size=2 face="sans-serif"> Note: Future meetings
(2015) will be using Rajan's 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: Final draft sent
to ISO for review. Will come back to Jim for final check (still not sent
back from ISO).</font>
<br><font size=2 face="sans-serif"> Date will need
to be set in the macro portion of the text. We will need to do the same
for parts 3 and 4.</font>
<br>
<br><font size=2 face="sans-serif"> Part 3: Comment resolution:</font>
<br><font size=2 face="sans-serif"> Suggested resolution
documents provided in WG14 meeting mailing.</font>
<br><font size=2 face="sans-serif"> Draft, assuming
all suggested responses are accepted, is ready. We can tell the committee
that the documents are ready for voting and only need document numbers.</font>
<br>
<br><font size=2 face="sans-serif"> Part 4: Comment resolution:</font>
<br><font size=2 face="sans-serif"> Suggested resolution
documents provided in WG14 meeting mailing.</font>
<br><font size=2 face="sans-serif"> Draft, assuming
all suggested responses are accepted, is ready. We can tell the committee
that the documents are ready for voting and only need document numbers.</font>
<br>
<br><font size=2 face="sans-serif"> Part 5: (Email discussion
based on email from Jim today)</font>
<br><font size=2 face="sans-serif"> Evaluation formats:</font>
<br><font size=2 face="sans-serif"> ToDo: Part
5: Evaluation Formats: Jim: Should be "value of FLT_EVAL_METHOD".</font>
<br><font size=2 face="sans-serif"> ToDo: Part
5: Evaluation Formats: Jim: "Use of other values of width" ->
"Use of unsupported values of width"</font>
<br><font size=2 face="sans-serif"> Issue #1:
OK</font>
<br><font size=2 face="sans-serif"> Issue #2:
No.</font>
<br><font size=2 face="sans-serif"> Value changing
optimizations:</font>
<br><font size=2 face="sans-serif"> Issue #3:
Leave open.</font>
<br><font size=2 face="sans-serif"> Points
brought up: Consistency with other STDC pragmas, more descriptive to use
ALLOW/DISALLOW, long name to type.</font>
<br><font size=2 face="sans-serif"> Issue #4:
Remove/reword text as it is invalid.</font>
<br><font size=2 face="sans-serif"> The
optimizations can consist of converting division to multiplication so it
is not just type changing.</font>
<br><font size=2 face="sans-serif"> Issue #5:
No.</font>
<br><font size=2 face="sans-serif"> Usually
binary and DFP are in different sections so they can use the #pragma for
those sections. i.e. They are usually not interspersed.</font>
<br><font size=2 face="sans-serif"> Issue #6:
Leave separate for now.</font>
<br><font size=2 face="sans-serif"> The
IEEE standard is explicit about both of these so even though FP_CONTRACT
covers it we will leave it in.</font>
<br><font size=2 face="sans-serif"> Allow wider
intermediate results:</font>
<br><font size=2 face="sans-serif"> The
FENV eval method takes care of this.</font>
<br><font size=2 face="sans-serif"> ToDo:
Jim: Remove it and say that the #pragma STDC FENV_FLT_EVAL_METHOD width
takes care of it.</font>
<br><font size=2 face="sans-serif"> Issue #7:
Keep open.</font>
<br><font size=2 face="sans-serif"> Should
we say a general rule that more specific pragma's override the general
ones?</font>
<br><font size=2 face="sans-serif"> Perhaps
group them or list the interactions?</font>
<br><font size=2 face="sans-serif"> Issue #8:
Open in modified form.</font>
<br><font size=2 face="sans-serif"> The
division one is important.</font>
<br><font size=2 face="sans-serif"> The
question is whether to provide it to give the same syntax for everyone
or leave it open for implementations to decide including potentially incompatible
ones.</font>
<br><font size=2 face="sans-serif"> Compiler's
would probably prefer to have less to implement.</font>
<br><font size=2 face="sans-serif"> Users
would probably prefer more control.</font>
<br><font size=2 face="sans-serif"> List
the ones we consider important and list the rest as ones considered.</font>
<br><font size=2 face="sans-serif"> Reproducible results:</font>
<br><font size=2 face="sans-serif"> Must use
correctly rounded functions, no wider format evaluation, etc. If something
else is used, you don't have reproducible results.</font>
<br><font size=2 face="sans-serif"> Math functions
that are not correctly rounded? Have a separate directive for transcendental
functions?</font>
<br><font size=2 face="sans-serif"> Issue #9:
More to talk about next time.</font>
<br><font size=2 face="sans-serif"> For
which parts:</font>
<br><font size=2 face="sans-serif">
All implementations with the same parts?</font>
<br><font size=2 face="sans-serif"> Disallow/Diagnose
non-reproducible constructs:</font>
<br><font size=2 face="sans-serif">
One view is to turn off things that could affect reproducibility, other
is to diagnose things that may be not reproducible.</font>
<br><font size=2 face="sans-serif">
Should be generating reproducible code.</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>