<font size=2 face="sans-serif"> <b>Attendees</b>: Rajan, Jim, Fred,
Mike, David H., 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><br><font size=2 face="sans-serif"><b> Carry over action items:</b></font><br><font size=2 face="sans-serif"> Ian: See if there is an
incompatibility between C and C++ for constants being evaluated to a wider
format (Ex. FLT_EVAL_METHOD affects constants in C++, and wider return
values) - Keep open (Hubert: Not defined and left up to C)</font><br><font size=2 face="sans-serif"> Jim: Update the binding
table in parts 1 and 2 to handle the new IEEE-754:2018 functions when published.
- Keep open.</font><br><font size=2 face="sans-serif"> David: Check the min/max
C specification to ensure it matches what IEEE has. - Not done.</font><br><font size=2 face="sans-serif"> David: Check the augmented*
C function specifications to ensure they match what IEEE has. - Not done.</font><br><font size=2 face="sans-serif"> All: totalorder* differ
for NaN payloads: Note that we don’t have approval to move up to 754 201x
yet. - Keep open: Revisit after we move up to the 754 draft.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"><b> Last meeting action items:</b></font><br><font size=2 face="sans-serif"> Jim: Remove for quantum
specification: “If x is NaN, the result is NaN”. - Done.</font><br><font size=2 face="sans-serif"> Jim: Make the change to
specify F.10.10a part 1 append as per Jim’s binding meeting minutes email
on 2018/08/23. - Done.</font><br><font size=2 face="sans-serif"> Fred: See which other
functions have the need to not trigger signaling NaNs but are functions
(need to be macros or have pointer parameters). - Done.</font><br><font size=2 face="sans-serif"> All: Look into comparison
macros and how to work them to avoid SNaN’s from signaling. - Done.</font><br><font size=2 face="sans-serif"> Jim: Create a part 1 CR
to make the totalorder* functions take pointer arguments. - Done.</font><br><font size=2 face="sans-serif"> David: Look into the identity
conflicts for sqrt and rootn in IEEE. - Done (in 754).</font><br><font size=2 face="sans-serif"> Jim: Part 4: Make the
change as per Jim’s 2018/06/26 email about specification for inexact with
making the required operations raise inexact IFF it is inexact. - Done.</font><br><font size=2 face="sans-serif"> Jim: Part 1: Make the
changes to next* as per Jim’s email on 2018/08/20. - Done.</font><br><font size=2 face="sans-serif"> Fred: Give reference to
the C DR for normalized double double meaning bits can be changed. - Done.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"><b> New action items:</b></font><br><font size=2 face="sans-serif"> All: Consider the fact
that C doesn't support the SNaN sequence that IEEE does. Can have strtod
take it as input.</font><br><font size=2 face="sans-serif"> Rajan: Draft a paper on
macro vs function (pointer vs arguments) causing signalling asking for
recommendations from WG14 or ask if it is a problem for anyone.</font><br><font size=2 face="sans-serif"> Jim: Fix the sqrt and
rootn identity conflicts with IEEE.</font><br><font size=2 face="sans-serif"> Fred: Ensure pown matches
IEEE for the identity conflicts.</font><br><br><font size=2 face="sans-serif"><b> Next Meeting(s):</b></font><br><font size=2 face="sans-serif"> Wednesday, October 24th,
2018, 11:00 EDT, 8:00 PST, 3PM UTC</font><br><font size=2 face="sans-serif"> Same teleconference number.</font><br><br><font size=2 face="sans-serif"> Next WG14 meeting (Pittsburgh,
2018/10/15).</font><br><br><font size=2 face="sans-serif"><b> Discussion:</b></font><br><font size=2 face="sans-serif"> IEEE 754 revision:</font><br><font size=2 face="sans-serif"> Issues with getting
a vote for the sponsored ballot.</font><br><font size=2 face="sans-serif"> Looks to be a 2019
revision.</font><br><font size=2 face="sans-serif"> There will be an
update meeting after the ballot.</font><br><font size=2 face="sans-serif"> Requires the IEEE
spreadsheet for comments.</font><br><font size=2 face="sans-serif"> Won't get an IEC
# until after it is an IEEE standard.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> C++ liaison:</font><br><font size=2 face="sans-serif"> Nothing.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Action item details (</font><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2288.pdf"><font size=2 color=blue face="sans-serif">http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2288.pdf</font></a><font size=2 face="sans-serif">):</font><br><font size=2 face="sans-serif"> Min/max C specification
matches IEEE?</font><br><font size=2 face="sans-serif"> Leave for
next meeting.</font><br><br><font size=2 face="sans-serif"> Augmented* C function
specifications match IEEE? </font><br><font size=2 face="sans-serif"> Not quite
finalized yet.</font><br><font size=2 face="sans-serif"> Leave for
next meeting.</font><br><br><font size=2 face="sans-serif"> Remove for quantum
specification: “If x is NaN, the result is NaN”. See Jim’s 9/3 email
“AIs to update working drafts” </font><a href="http://wiki.edg.com/pub/CFP/WebHome/cfp2x-20180903.pdf"><font size=2 color=blue face="sans-serif">http://wiki.edg.com/pub/CFP/WebHome/cfp2x-20180903.pdf</font></a><br><font size=2 face="sans-serif"> Looks good.</font><br><br><font size=2 face="sans-serif"> Make the change
to specify F.10.10a part 1 append as per Jim’s binding meeting minutes
email on 2018/08/23.</font><br><font size=2 face="sans-serif"> See Jim’s 9/3
email “AIs to update working drafts” </font><a href="http://wiki.edg.com/pub/CFP/WebHome/cfp1x-20180903.pdf"><font size=2 color=blue face="sans-serif">http://wiki.edg.com/pub/CFP/WebHome/cfp1x-20180903.pdf</font></a><br><font size=2 face="sans-serif"> Looks good.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> See which other
functions have the need to not trigger signaling NaNs but are functions
(need to be macros or have pointer parameters).</font><br><font size=2 face="sans-serif"> See Fred’s 8/28
email “Not trigger sNaN” and responses </font><br><font size=2 face="sans-serif"> Jim responded
on the 9/16 email.</font><br><font size=2 face="sans-serif"> Mike: samequantum
is intended to not trigger the SNaN. Intended to return a flag. Will discuss
in the IEEE group.</font><br><font size=2 face="sans-serif"> printf:
Fred: Does canonicalize trigger SNaN's since it takes a pointer?</font><br><font size=2 face="sans-serif"> Jim: Yes,
it is a convert operation so it does (part 1 explicitly says it).</font><br><font size=2 face="sans-serif"> strtod/scanf:
We don't say anything about this. Within C alone it is not a problem. Only
when reading a character sequence from outside which may have an SNaN.
Related to the NANS proposal.</font><br><font size=2 face="sans-serif"> Fred: IEEE-854
says the first characters for a nan should be NaN, but can be followed
by whatever else. Note that this is incompatible with 754.</font><br><br><font size=2 face="sans-serif"> Look into comparison
macros and how to work them to avoid SNaN’s from signaling. Create a part
1 CR to make the totalorder* functions take pointer arguments. </font><br><font size=2 face="sans-serif"> </font><a href=http://wiki.edg.com/pub/CFP/WebHome/n2292.pdf><font size=2 color=blue face="sans-serif">http://wiki.edg.com/pub/CFP/WebHome/n2292.pdf</font></a><font size=2 face="sans-serif"></font><br><font size=2 face="sans-serif"> See also Joseph
Myers 9/11 email “(SC22WG14.15517) totalorder and tgmath.h” </font><br><font size=2 face="sans-serif"> For totalorder,
argument vs pointer, the intent seems to be for fast functions.</font><br><font size=2 face="sans-serif"> Fred: Seems
to be a problem with Intel's float and double being promoted to long double
which would cause a signal.</font><br><font size=2 face="sans-serif"> Fred: For
fabs, it could be a BIF, but if the user code takes a function pointer
to it, then any call through that function pointer would trigger the signal.</font><br><font size=2 face="sans-serif"> Fred: Can
test this.</font><br><font size=2 face="sans-serif"> Jim: We
could have an input SNaN macro if what we have specified is not practically
implementable.</font><br><font size=2 face="sans-serif"> *AI*: Rajan:
Draft a paper on macro vs function (pointer vs arguments) causing signalling
asking for recommendations from WG14 or ask if it is a problem for anyone.</font><br><font size=2 face="sans-serif"> Note that
a CR should deal with the functions tgmath list fix-up</font><br><br><font size=2 face="sans-serif"> Look into the identity
conflicts for sqrt and rootn in IEEE. </font><br><font size=2 face="sans-serif"> There was
agreement in 754 to not change. That leaves it to us to change. We will
need to expand out the cases.</font><br><font size=2 face="sans-serif"> *AI*: Jim:
Fix the sqrt and rootn identity conflicts with IEEE.</font><br><font size=2 face="sans-serif"> Another
identity conflict function was pown. We agree with IEEE there.</font><br><font size=2 face="sans-serif"> *AI*: Fred:
Ensure pown matches IEEE for the identity conflicts.</font><br><br><font size=2 face="sans-serif"> Part 4: Make the
change as per Jim’s 2018/06/26 email about specification for inexact with
making the required operations raise inexact IFF it is inexact.</font><br><font size=2 face="sans-serif"> See Jim’s 9/3
email “AIs to update working drafts” </font><a href="http://wiki.edg.com/pub/CFP/WebHome/cfp4x-20180903.pdf"><font size=2 color=blue face="sans-serif">http://wiki.edg.com/pub/CFP/WebHome/cfp4x-20180903.pdf</font></a><br><font size=2 face="sans-serif"> Page 16,
~line 10: Second sentence: Looks good.</font><br><br><font size=2 face="sans-serif"> Part 1: Make the
changes to next* as per Jim’s email on 2018/08/20.</font><br><font size=2 face="sans-serif"> See Jim’s 9/3
email “AIs to update working drafts” </font><a href="http://wiki.edg.com/pub/CFP/WebHome/cfp1x-20180903.pdf"><font size=2 color=blue face="sans-serif">http://wiki.edg.com/pub/CFP/WebHome/cfp1x-20180903.pdf</font></a><font size=2 face="sans-serif"></font><br><font size=2 face="sans-serif"> Page 42:
Looks good.</font><br><font size=2 face="sans-serif"> Fred: Wanted
to add the "if the result is finite, the value is normalized, sub-normal,
or ..." to the main body of the standard.</font><br><font size=2 face="sans-serif"> Fred: It
is not clear what nextup of 1 is on a double double system. Is it supposed
to be representable in the model or the hardware?</font><br><font size=2 face="sans-serif"> Jim: Says
the type of the function.</font><br><font size=2 face="sans-serif"> Ian: That
would be the smallest positive sub-normal.</font><br><br><font size=2 face="sans-serif"> Give reference
to the C DR for normalized double double meaning bits can be changed.</font><br><font size=2 face="sans-serif"> See Fred’s 8/28
email “Normalized numbers” </font><br><font size=2 face="sans-serif"> Jim replied
on 9/22, Fred replied to that on the same day.</font><br><font size=2 face="sans-serif"> CR 432:
Looks good.</font><br><font size=2 face="sans-serif"> CR 467:
p needs to be variable for double-double.</font><br><font size=2 face="sans-serif"> Normalized
number: The rest of the sentence is still there.</font><br><font size=2 face="sans-serif"> Jim:
The fk any digits part does not have to be there since it can't be any
other way.</font><br><font size=2 face="sans-serif"> Fred:
The double-double case is where you have the issue where the numbers are
not part of the model, but allowed. Those numbers are not normalized. This
change disallows them from being normalized.</font><br><font size=2 face="sans-serif"> Not
intending to make double-double a part of the standard.</font><br><font size=2 face="sans-serif"> Fred:
Not sure what would be most useful. It would at least be well defined.</font><br><font size=2 face="sans-serif"> Jim:
I think it is well defined now. It would just be different from what is
there now.</font><br><font size=2 face="sans-serif"> Fred:
I think it is ambiguous now.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Other issues? </font><br><font size=2 face="sans-serif"> None.</font><br><br><font size=2 face="sans-serif"> Activities in progress:</font><br><font size=2 face="sans-serif"> Leave for later.</font><br><font size=2 face="sans-serif"> </font><BR>