<font size=2 face="sans-serif"><b>Attendees</b>: Rajan, Jim, Fred, David,
Mike, Ian</font><br><br><font size=2 face="sans-serif"><b>New agenda items</b>:</font><br><font size=2 face="sans-serif"> Maintenance to the published
parts of the TS</font><br><font size=2 face="sans-serif"> Part 1 comments from Fred</font><br><br><font size=2 face="sans-serif"><b>Last meeting action items</b>:</font><br><font size=2 face="sans-serif"> Ian: Talk to Lawrence
Crawl regarding proposing this IEEE-754: 2008 binding to C++ as well. -
In process.</font><br><font size=2 face="sans-serif"> No response from
Lawrence to an email sent by Ian.</font><br><font size=2 face="sans-serif"> Ian: Update and check
the items listed and flagged under Feature_List_Part_1. - Not done.</font><br><font size=2 face="sans-serif"> David: See what Oracle
has done for the feature lists. - Done</font><br><font size=2 face="sans-serif"> Not much present.
They do have Fred's test suite. No DFP yet.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Rajan: Get Mike in contact
with Jens to get access to the C Standard source in the GIT repository.
- Done.</font><br><font size=2 face="sans-serif"> Copy Jim on this
as well.</font><br><font size=2 face="sans-serif"> Jim: p13: line 22: Add
in a statement describing the remaining bullets to show they are not a
complete list. - Done.</font><br><font size=2 face="sans-serif"> Jim: p17: line 27: List
the actions in place of "below" or say "the remaining actions
in this sub-clause". - Done.</font><br><font size=2 face="sans-serif"> All: Consider mixed nested
try and delayed try blocks and look for cases not covered by the specification.
- Done. Not reflected in the current draft.</font><br><font size=2 face="sans-serif"> All: Focused Review of
part 5 once the updated draft comes out. - Delayed to handle comments from
Joseph.</font><br><br><font size=2 face="sans-serif"><b>New action items</b>:</font><br><font size=2 face="sans-serif"> Jim: Part 5: Page 2: Review
the change to see if clarification is needed regarding "after"
referring to time or source code.</font><br><font size=2 face="sans-serif"> Jim: Part 5: Page 18:
Line 45: Reword to make it clearer.</font><br><font size=2 face="sans-serif"> Jim: Part 5: Page 20,
21: Change the '#define n' to '#define NUMBER_OF_ELEMENTS'.</font><br><font size=2 face="sans-serif"> Jim: Part 5: Page 21:
Change the "for (i=0;" to "for (int i=0;"</font><br><font size=2 face="sans-serif"> Jim: Get the changebar'd
and dated version of previous TS's on the wiki to review.</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"> February 16th, 2016, 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"> WG14 mailing is March
14th, 2016. Meeting is April 11-15th, 2016 at BSI, London, England.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> IEEE 754 revision:</font><br><font size=2 face="sans-serif"> Progress being
made.</font><br><font size=2 face="sans-serif"> Expecting new policies
and procedures.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Arith23:</font><br><font size=2 face="sans-serif"> Nothing new.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Part 5: Various emails,
documents (cfp5-20160105.pdf [</font><a href="http://wiki.edg.com/bin/login/CFP/WebHome?origurl=/pub/CFP/WebHome/cfp5-20160105.pdf"><font size=2 color=blue face="sans-serif">http://wiki.edg.com/bin/login/CFP/WebHome?origurl=/pub/CFP/WebHome/cfp5-20160105.pdf</font></a><font size=2 face="sans-serif">]):</font><br><font size=2 face="sans-serif"> Copyright dates
changed (except page ii as that is an image).</font><br><font size=2 face="sans-serif"> *Page 2 change:
Review this to see if clarification is needed regarding "after"
referring to time or source code.</font><br><font size=2 face="sans-serif"> Saying "after
the signal handler completes." will make it unambiguous.</font><br><font size=2 face="sans-serif"> Does this
apply to all the standard pragmas?</font><br><font size=2 face="sans-serif"> Seems
to be safer to have it apply to everything since there would be no implementation
assumptions.</font><br><font size=2 face="sans-serif"> Page 5: Good.</font><br><font size=2 face="sans-serif"> Page 6 change 1:
Good.</font><br><font size=2 face="sans-serif"> Page 6 change 2:
Good.</font><br><font size=2 face="sans-serif"> Page 9 change 1
(comment 5): Good.</font><br><font size=2 face="sans-serif"> Page 9 change 2
(comment 6): Good.</font><br><font size=2 face="sans-serif"> IEEE does
not say anything regarding to this.</font><br><font size=2 face="sans-serif"> For alternate
exception handling, it is specified.</font><br><font size=2 face="sans-serif"> For optimization
allowance it is not.</font><br><font size=2 face="sans-serif"> Page 10: Good.</font><br><font size=2 face="sans-serif"> Page 15 change
1 (line 7): Good.</font><br><font size=2 face="sans-serif"> Fits better
with existing C language since it does not exclude complex.</font><br><font size=2 face="sans-serif"> Page 15 change
2 (comment 8): Good.</font><br><font size=2 face="sans-serif"> Page 15 change
3 (comment 7, 9):</font><br><font size=2 face="sans-serif"> Any requirement
to make the values distinct?</font><br><font size=2 face="sans-serif"> No.
The use is still for the list of exceptions. The values are a form to allow
testing for existence.</font><br><font size=2 face="sans-serif"> Fred: On
page 18 line 45 they seem to need to be distinct.</font><br><font size=2 face="sans-serif"> Ex.
The IBM implementation has sub-exceptions that set the parent exception
flag bit as well.</font><br><font size=2 face="sans-serif"> *Jim:
That is an assumption. Maybe the words need to be changed to be clearer.</font><br><font size=2 face="sans-serif"> Page 18: Good (barring
above).</font><br><font size=2 face="sans-serif"> Fred's comment/email
regarding jumps (line 21): C standard defines jumps (6.8.6) without longjmp
and raise.</font><br><font size=2 face="sans-serif"> Page
19 handles raise(SIGFPE) but not any other raise.</font><br><font size=2 face="sans-serif"> Note
this also applies to any other non-returning function calls like quick_exit,
etc.</font><br><font size=2 face="sans-serif"> The
C Standard definition is for the grammar, not the general english term
being used here.</font><br><font size=2 face="sans-serif"> Page 19 change
1: Good.</font><br><font size=2 face="sans-serif"> Page 19 change
2 (comment 13): Good.</font><br><font size=2 face="sans-serif"> Fred: Do
any of our TS parts tie together exceptions and SIGFPE?</font><br><font size=2 face="sans-serif"> No.
Not specified by us. The C standard already has words about how it can
interact and result in undefined behaviour.</font><br><font size=2 face="sans-serif"> We don't
want to get into signalling here if we can avoid it.</font><br><font size=2 face="sans-serif"> What does
'scope' refer to here? The FENV_EXCEPT pragma given in the line before.</font><br><font size=2 face="sans-serif"> Page 20: Good.</font><br><font size=2 face="sans-serif"> Suggestion:
Change the '#define n' to '#define NUMBER_OF_ELEMENTS'</font><br><font size=2 face="sans-serif"> Page 21: Good.</font><br><font size=2 face="sans-serif"> Suggestion:
Change the "for (i=0;" to "for (int i=0;"</font><br><font size=2 face="sans-serif"> Page 22, 23 (comments
8, 11, 14): Good.</font><br><font size=2 face="sans-serif"> If the sub-exception
did not set the parent exception, this would break this code.</font><br><font size=2 face="sans-serif"> The nested
immediate 'try's have undefined behaviour (what is y's value?) due to the
jump out of the inner 'try'.</font><br><font size=2 face="sans-serif"> Fred: Perhaps
on page 18 we should list nested try blocks as part of the jumps list as
well.</font><br><font size=2 face="sans-serif"> This
would be like listing everything else too. Why just this case?</font><br><font size=2 face="sans-serif"> Another
possible example would be ALL_EXCEPT with a particular exception.</font><br><font size=2 face="sans-serif"> Perhaps
have examples with other exceptions?</font><br><font size=2 face="sans-serif"> Recent versions
of LAPACK do exploit IEEE exception handling by using isnan.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Comment 9: Probably
is common in implementation of libraries.</font><br><font size=2 face="sans-serif"> Note that
sub-exceptions are a optional part of an optional TS so should not be that
large a burden.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Are we ready for
the focused review after the changes listed above?</font><br><font size=2 face="sans-serif"> Yes.</font><br><br><font size=2 face="sans-serif"> Maintenance to the published
parts of the TS:</font><br><font size=2 face="sans-serif"> Some changes are
present in the editors draft (but not the published one).</font><br><font size=2 face="sans-serif"> Jim to get the
changebar'd dated version on the wiki to review.</font><br><font size=2 face="sans-serif"> After approval,
need to create a DR for the changes.</font><br><font size=2 face="sans-serif"> Editorial
can be all in a single DR per TS.</font><br><font size=2 face="sans-serif"> Other changes
can be individual DR's.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Parts 1 and 2 implementations
in practice:</font><br><font size=2 face="sans-serif"> Should we bring
up individual features from these parts to the C standard for inclusion?</font><br><font size=2 face="sans-serif"> Part 1 has a lot
of new functions that narrow the results of the arguments. Not a lot of
implementation seen.</font><br><font size=2 face="sans-serif"> Jim: Intel
may have implemented this.</font><br><font size=2 face="sans-serif"> Fred: No
floating point exception flags for DFP implemented in Intel.</font><br><font size=2 face="sans-serif"> Jim:
HP did.</font><br><font size=2 face="sans-serif"> Having the entire
TS parts is a high bar. Not suitable for an Annex either since it is modifications
to the standard.</font><br><font size=2 face="sans-serif"> Ian: Having the
syntax for the new floating point literals should be brought in.</font><br><font size=2 face="sans-serif"> Rajan: The TS's
should have implementation somewhere (as long as the aggregate of implementations
cover the entire TS) to help get WG14 approval to bring it into the standard.
Individual proposals of parts of the TS's for standardization is fine,
but we should not do it as a group.</font><br><font size=2 face="sans-serif"> Fred: The DEC alpha
chip does static rounding.</font><br><font size=2 face="sans-serif"> May not
be like ours.</font><br><font size=2 face="sans-serif"> Make this a more
significant item to discuss in the next meeting.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Part 1 comments from Fred
(email on 2016/01/05):</font><br><font size=2 face="sans-serif"> Seem valid comments.</font><br><font size=2 face="sans-serif"> Review these items
next meeting (follow up in email until Fred leaves).</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><BR>