<font size=2 face="sans-serif"> <b>Attendees</b>: Rajan, Jim, Fred,
Mike, David H., Ian, David C.</font><br><br><font size=2 face="sans-serif"><b> New agenda items:</b></font><br><font size=2 face="sans-serif"> Fred's emails</font><br><font size=2 face="sans-serif"> Adding attributes to C
paper</font><br><font size=2 face="sans-serif"> IEEE 754-2018 changes
review</font><br><font size=2 face="sans-serif"> Fred: Missing a
number of functions that were added. Ex. fadd that returns a float from
double args.</font><br><font size=2 face="sans-serif"> David H: It was
already there in the 2008 standard.</font><br><br><font size=2 face="sans-serif"><b> Last meeting action items:</b></font><br><font size=2 face="sans-serif"> Jim: Activities in progress:
Obsolesce DECIMAL_DIG: No proposal needed as our last one was accepted
(N2108) - Done.</font><br><font size=2 face="sans-serif"> Jim: Activities in progress:
%a for decimal differing from binary: Change "paper" to Reflector
message 14792. - Done.</font><br><font size=2 face="sans-serif"> Jim: Activities in progress:
Change all TS Part actions to "update and re-present" instead
of just re-present. - Done.</font><br><font size=2 face="sans-serif"> Jim: Get document number
and submit DECIMAL_DIG and DIG macros for non-arithmetic formats paper
for the WG14 mailing. - Done (N2171).</font><br><font size=2 face="sans-serif"> Jim: Write a DR for the
_Roundwise in cbrt sample for the WG14 mailing. - Done (N2178).</font><br><font size=2 face="sans-serif"> David H, Mike: Make a
list of what has changed or been augmented in IEEE 754:2018. - Done.</font><br><font size=2 face="sans-serif"> Jim: Augmented arithmetic:
F.10.13 is missing the paragraph number in the second paragraph. - Done.</font><br><font size=2 face="sans-serif"> Jim: Augmented arithmetic:
F.10.13.3#4: computation t underflows -> computation of t underflows
- Done.</font><br><font size=2 face="sans-serif"> Jim: Min/Max functions:
Mention that the existing fmin/fmax functions do not distinguish bewteen
+0 and -0. - Done.</font><br><font size=2 face="sans-serif"> Jim: Draft a response
to Willem's WG14 paper (N2166) for next meeting. - Done.</font><br><br><font size=2 face="sans-serif"><b> New action items:</b></font><br><font size=2 face="sans-serif"> Jim: Activities: Add in
WG14 document numbers to the items that have them.</font><br><font size=2 face="sans-serif"> Rajan: %a precision: If
the footnote is wanted by WG14, correct the typo (differs is several ways
-> differs in several ways)</font><br><font size=2 face="sans-serif"> Rajan: %a precision: If
the footnote is wanted by WG14, change "For example" into "For
instance"</font><br><font size=2 face="sans-serif"> Jim: Respond to WG14 reflector
message 14812 with the need to have it predictable and fixed</font><br><font size=2 face="sans-serif"> Jim: Send WG14 N1361 to
the CFP group</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)</font><br><font size=2 face="sans-serif"> Rajan: Willem's paper
point 4 (return value): No consensus but are OK with either way and if
no change, we should note that function return format is not being affected
by FLT_EVAL_METHOD</font><br><font size=2 face="sans-serif"> Fred: Get the latest C
standard paper to the group</font><br><font size=2 face="sans-serif"> All: Discuss via email
Fred's email on 2017/09/21 about Annex F the TS. Potential DR for part
1.</font><br><font size=2 face="sans-serif"> Jim: Send out alternate
proposal incorporating Willem's points this group agrees on.</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"> Tuesday November 14th,
2017, 12:00 EDT, 9:00 PST</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"> IEEE 754 revision:</font><br><font size=2 face="sans-serif"> Not much change
since last meeting.</font><br><font size=2 face="sans-serif"> Still debating
on adding payload functions.</font><br><font size=2 face="sans-serif"> Proposing
deferring.</font><br><font size=2 face="sans-serif"> Still debating
changing rounding mode for the augmented functions.</font><br><font size=2 face="sans-serif"> Proposing
freezing current wording.</font><br><font size=2 face="sans-serif"> Aside: Don't say
"table" something as it means different things (opposite) in
different countries or is ambiguous.</font><br><br><font size=2 face="sans-serif"> C++ liaison:</font><br><font size=2 face="sans-serif"> No update.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Activities (</font><a href="http://wiki.edg.com/pub/CFP/WebHome/in_flight-20171004.pdf"><font size=2 color=blue face="sans-serif">http://wiki.edg.com/pub/CFP/WebHome/in_flight-20171004.pdf</font></a><font size=2 face="sans-serif">):</font><br><font size=2 face="sans-serif"> For updating to
754:2018: Just need a list of changes with some small description.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> For next WG14 meeting:</font><br><font size=2 face="sans-serif"> Decimal Dig and
Dig macros (</font><a href=http://wiki.edg.com/pub/CFP/WebHome/n2171.pdf><font size=2 color=blue face="sans-serif">http://wiki.edg.com/pub/CFP/WebHome/n2171.pdf</font></a><font size=2 face="sans-serif">):</font><br><font size=2 face="sans-serif"> Looks good.</font><br><font size=2 face="sans-serif"> %a consistency
(WG14 reflector message 14792):</font><br><font size=2 face="sans-serif"> Typo: differs
is several ways -> differs in several ways</font><br><font size=2 face="sans-serif"> For example
-> For instance</font><br><font size=2 face="sans-serif"> _Roundwise in cbrt
(</font><a href=http://wiki.edg.com/pub/CFP/WebHome/n2178.pdf><font size=2 color=blue face="sans-serif">http://wiki.edg.com/pub/CFP/WebHome/n2178.pdf</font></a><font size=2 face="sans-serif">):</font><br><font size=2 face="sans-serif"> Clark asked
(WG14 reflector message 14810) why SHALL vs MIGHT.</font><br><font size=2 face="sans-serif"> Likely
due to ease of implementation and efficiency (performance for example).</font><br><font size=2 face="sans-serif"> It
is this way to keep it predictable and consistent and reproducible.</font><br><font size=2 face="sans-serif"> The
user has explicitly added the pragma so they want something fixed.</font><br><font size=2 face="sans-serif"> Continue sending
DRs to Blaine as web form format.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Binding for IEEE 754-2018:</font><br><font size=2 face="sans-serif"> Focus on TC for
the next WG14 meeting so no need to bring this up in the meeting.</font><br><font size=2 face="sans-serif"> Better to have
754:2018 finalized before submitting to WG14 anyways.</font><br><font size=2 face="sans-serif"> Augmented arithmetic
(</font><a href="http://wiki.edg.com/pub/CFP/WebHome/augop_spec-20170930.pdf"><font size=2 color=blue face="sans-serif">http://wiki.edg.com/pub/CFP/WebHome/augop_spec-20170930.pdf</font></a><font size=2 face="sans-serif">):</font><br><font size=2 face="sans-serif"> Looks good.</font><br><font size=2 face="sans-serif"> After finalization
of 754:2018, ensure it is still correct and in sync before presenting to
WG14.</font><br><font size=2 face="sans-serif"> Fred: Should
the augmul case call out what is invalid?</font><br><font size=2 face="sans-serif"> David: It
should follow 754 since this a special case of the normal multiply (augmented).</font><br><font size=2 face="sans-serif"> Fred: Invalid
is well defined in 754, but not in C.</font><br><font size=2 face="sans-serif"> Jim: We
should only specify what 754 specifies for Annex F.</font><br><font size=2 face="sans-serif"> min/max (</font><a href="http://wiki.edg.com/pub/CFP/WebHome/min-max_spec-20170930.pdf"><font size=2 color=blue face="sans-serif">http://wiki.edg.com/pub/CFP/WebHome/min-max_spec-20170930.pdf</font></a><font size=2 face="sans-serif">):
</font><br><font size=2 face="sans-serif"> Looks good.</font><br><font size=2 face="sans-serif"> Payload functions:</font><br><font size=2 face="sans-serif"> Leave as
is.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Other:</font><br><font size=2 face="sans-serif"> Willem Wakker issues
about evaluation formats (</font><a href="http://wiki.edg.com/pub/CFP/WebHome/WW_evaluation_formats-20171007.pdf"><font size=2 color=blue face="sans-serif">http://wiki.edg.com/pub/CFP/WebHome/WW_evaluation_formats-20171007.pdf</font></a><font size=2 face="sans-serif">)</font><br><font size=2 face="sans-serif"> 1) Jim:
A lot of the floating point stuff is in section 5, not in 6.</font><br><font size=2 face="sans-serif"> 2) The concern
he had doesn't seem to apply to the actual wording after DR500.</font><br><font size=2 face="sans-serif"> Fred:
If you have FLT_EVAL_METHOD as -1 then you don't know when it applies.</font><br><font size=2 face="sans-serif"> Jim:
That's the point of -1.</font><br><font size=2 face="sans-serif"> Fred:
The answer to Willem's question is "may" refers to the case where
FLT_EVAL_METHOD is -1.</font><br><font size=2 face="sans-serif"> Jim:
No, since FLT_EVAL_METHOD is the specific method of wide evaluation (if
done).</font><br><font size=2 face="sans-serif"> 3) Jim wrote
a paper (N1361) to keep constants being affected by the evaluation format.
It was already looked at by the committee and agreed to.</font><br><font size=2 face="sans-serif"> 4) Fred:
Already wrote a paper to have 'return' act like cast and assignment.</font><br><font size=2 face="sans-serif"> Jim:
This was already discussed before and we decided to allow wider return
values.</font><br><font size=2 face="sans-serif"> Ian:
This would result in store and load on x86 (without SSE2 floating point
- ABI incompatibility on register of return value).</font><br><font size=2 face="sans-serif"> The
value has to be in the range of a float exponent and same precision for
example, even if stored in a double register.</font><br><font size=2 face="sans-serif"> For
our group, we don't have a position as we did bind to IEEE as per Annex
F, and it is not our issue. It is more of a C issue.</font><br><font size=2 face="sans-serif"> There
is a portability hole. It is unlike the other parts that are affected by
FLT_EVAL_METHOD.</font><br><font size=2 face="sans-serif">
Jim: Without Annex F, if FLT_EVAL_METHOD is 0, then you know what happens
with casts, assignments, parameters, etc. but not about function returns.</font><br><font size=2 face="sans-serif">
Fred: This was covered in C99 + TC3. It was taken out in C11. The argument
was it was added into C99 by accident.</font><br><font size=2 face="sans-serif">
Ian: It should be noted in the standard if nothing is done so it is clear
to the standard reader that function return format not being affected by
FLT_EVAL_METHOD is a hole.</font><br><font size=2 face="sans-serif"> For
WG14, can say we don't have consensus but are OK with either way and if
no change, to add the note as specified above.</font><br><font size=2 face="sans-serif"> Jim has
an alternate proposal that incorporates what we agree with from Willem's
paper. Will send it out to the group.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Other prep for
WG14 meeting</font><br><font size=2 face="sans-serif"> C standard use
of "floating" vs "floating-point"</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> All: Discuss via
email Fred's email on 2017/09/21 about Annex F the TS. Potential DR for
part 1.</font><BR>