<font size=2 face="sans-serif"><b>Attendees</b>: Rajan, Jim, David, Fred,
Marius, Mike*, Ian*</font><br><font size=2 face="sans-serif"> *First hour only</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><br><font size=2 face="sans-serif"><b>Last meeting action items</b>:</font><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
- Done</font><br><font size=2 face="sans-serif"> Michael suggested
talking with Lawrence Crawl (Numerics extension group in C++)</font><br><font size=2 face="sans-serif"> Question from them:
Should _Float64 be the same as double in the typedef sense? We explicitly
made it separate types. Has implications in name mangling and exception
handling.</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 - Drop the item</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> All: Review 7.6.1f.2 (in
part 5, Aug 28) and report by email - Done (discuss below)</font><br><font size=2 face="sans-serif"> Jim: Change P 14#5 to
say something like “for the listed exceptions” - Done</font><br><font size=2 face="sans-serif"> Jim: Write up change to
disallow exceptions from appearing in more than one catch or delayed-catch
list - Done</font><br><font size=2 face="sans-serif"> Jim: Try putting the input/results
for the examples in a table - Done</font><br><font size=2 face="sans-serif"> Jim: Improve wording in
last NOTE – change “delayed-catch” to “delayed-try and delayedcatch”
– clarify that last statement applies to try-catch – change “should”
to something like “might well be able to” - Done</font><br><font size=2 face="sans-serif"> Jim: Write up specification
from email proposal about evaluation methods and math functions and include
it in the draft - Done</font><br><br><font size=2 face="sans-serif"><b>New 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 -
Still to do</font><br><font size=2 face="sans-serif"> David: Send out an email
address to sign yourself up to the IEEE 754 mailing list to this group.</font><br><font size=2 face="sans-serif"> Ian: Update and check
the items listed and flagged under Feature_List_Part_1.</font><br><font size=2 face="sans-serif"> Jim: Send Mike an email
regarding what is needed regarding prior art/implementation for Part 1
features in other languages</font><br><font size=2 face="sans-serif"> Jim: p5: Give example
of what the macro would do and what would happen without it.</font><br><font size=2 face="sans-serif"> Jim: p12: See if we can
add a footnote regarding the implementation defined/unspecified/undefined
behavior referring to Annex J and/or an example from one of the bullets
ommitted.</font><br><font size=2 face="sans-serif"> Jim: p8: Make subnormal
zero case be something that should keep the same sign</font><br><font size=2 face="sans-serif"> Jim: p15: line 31: ilogb
-> ilogb and llogb</font><br><font size=2 face="sans-serif"> Jim: p15: line 32: FE_INVALID_LOGB
-> FE_INVALID_ILOGB</font><br><font size=2 face="sans-serif"> Jim: p16: line 10: Remove
'and round result to narrower type'.</font><br><font size=2 face="sans-serif"> Jim: p9: FENV_ALLOW_CONTRACT_FMA:
Send a note to convey this should not apply to any implementation/system
operations, and only to user code that is directly what is listed in lines
11-14.</font><br><br><font size=2 face="sans-serif"><b>Next Meeting</b>:</font><br><font size=2 face="sans-serif"> October 13th, 2015, 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"> WG14 mailing deadline
is September 28th.</font><br><br><font size=2 face="sans-serif"><b>Discussion</b>:</font><br><font size=2 face="sans-serif"> Part 3: Target publication
date: October 1st, 2015.</font><br><br><font size=2 face="sans-serif"> Part 4: No target publication
date yet.</font><br><br><font size=2 face="sans-serif"> IEEE 754 group (new revision
to the standard):</font><br><font size=2 face="sans-serif"> David still needs
to schedule the first meeting.</font><br><font size=2 face="sans-serif"> Can subscribe yourself.</font><br><font size=2 face="sans-serif"> *David: Send out
an email address to sign yourself up to the IEEE 754 mailing list to this
group.</font><br><br><font size=2 face="sans-serif"> ARITH23 (conference next
summer):</font><br><font size=2 face="sans-serif"> Marius: IBM, AMD,
Intel presented new things in hardware last time. This TS could be discussed
there.</font><br><font size=2 face="sans-serif"> Conference moving
to every year instead of every other year. Does not have to be latest in
research, but can be interesting things like state of the art hardware,
etc.</font><br><font size=2 face="sans-serif"> The presentation
could be the TS followed by the implementations by the vendors (Ex. IBM,
Intel, GCC) and IEEE-754:2008 overview, etc.</font><br><font size=2 face="sans-serif"> David: Generally
these panels want a diversity in points of view. Not interested in getting
input for the 2018 version of the IEEE-754 standard, but would be for 2028.</font><br><font size=2 face="sans-serif"> Marius: Should
I propose this? I will be there.</font><br><font size=2 face="sans-serif"> Jim: I can probably
attend and present the TS.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Feature Lists:</font><br><font size=2 face="sans-serif"> *Ian: Update and
check the items listed and flagged under Feature_List_Part_1.</font><br><font size=2 face="sans-serif"> Other languages
may have these functions so we could use this under prior art.</font><br><font size=2 face="sans-serif"> Mike may
know this from his test suite. *Jim to send Mike an email regarding what
is needed regarding prior art/implementation for Part 1 features in other
languages</font><br><font size=2 face="sans-serif"> Fred: GCC does
not honor binary rounding mode when converting from DFP to binary floating
point. It also has issues with rounding modes between decimal and binary
floating point. These are partial implementations.</font><br><br><font size=2 face="sans-serif"> Part 5: Various emails,
documents (cfp5-20150826.pdf)</font><br><font size=2 face="sans-serif"> p3/5: Examples
would help. *Jim: p5: Give example of what the macro would do and what
would happen without it.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Mike: 'BREAK' is
not a good term since it is a keyword if lower-case.</font><br><font size=2 face="sans-serif"> Case matters
so it seems fine the way it is.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Jim's September
9th email: Seems like a good approach</font><br><font size=2 face="sans-serif"> Perhaps
have a footnote to reference one of the bullets we'll be pulling out and/or
refer to Annex J?</font><br><font size=2 face="sans-serif"> *Jim: p12:
See if we can add a footnote regarding the implementation defined/unspecified/undefined
behavior referring to Annex J and/or an example from one of the bullets
ommitted.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Zero subnormal
sign issue (2015/09/14 email): </font><br><font size=2 face="sans-serif"> Make this
a 'should' statement.</font><br><font size=2 face="sans-serif"> *Jim: p8:
Make subnormal zero case be something that should keep the same sign</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> p15: Line 31/32:
Should FE_INVALID_LOGB be FE_INVALID_ILOGB since the line above should
refer to ilogb and llogb functions?</font><br><font size=2 face="sans-serif"> Suggestions:
FE_INVALID_ILOGB, FE_INVALID_I_LOGB, FE_INVALID_INTEGRAL_LOGB</font><br><font size=2 face="sans-serif"> Change it
to FE_INVALID_ILOGB.</font><br><font size=2 face="sans-serif"> *Jim: p15:
line 31: ilogb -> ilogb and llogb</font><br><font size=2 face="sans-serif"> *Jim: p15:
line 32: FE_INVALID_LOGB -> FE_INVALID_ILOGB</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> p16: Line 10: *Jim:
p16: line 10: Remove 'and round result to narrower type'.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> p9: Does ALLOW_CONTRACT_FMA
apply to user code only or behind the scene code like complex mul and div?</font><br><font size=2 face="sans-serif"> Jim: The
system code is a black box. This pragma should not affect that. Since the
user has no clue what is in the black box, it should not matter.</font><br><font size=2 face="sans-serif"> Does C say
anything about inline code being the same as something compiled in another
CU?</font><br><font size=2 face="sans-serif"> This issue
is not particular to this part of the TS. It is a wider question.</font><br><font size=2 face="sans-serif"> *Jim: p9:
FENV_ALLOW_CONTRACT_FMA: Send a note to convey this should not apply to
any implementation/system operations, and only to user code that is directly
what is listed in lines 11-14.</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><BR>