<font size=2 face="sans-serif"><b>Attendees</b>: Rajan, Fred</font><br><br><font size=2 face="sans-serif"><b>Papers:</b></font><br><font size=2 face="sans-serif"> N2172: Return and extra precision</font><br><font size=2 face="sans-serif"> The ABI can stay the same.
They just have to go through the knothole.</font><br><font size=2 face="sans-serif"> Blaine: Seems reasonable
other than inline functions.</font><br><font size=2 face="sans-serif"> Fred: That means if the
user uses inline or not can give different results on computations.</font><br><font size=2 face="sans-serif"> David: Often people are
encouraged to use static inline vs macros. Losing the extra range and precision
would hurt them.</font><br><font size=2 face="sans-serif"> Barry: What do compilers
do right now in standard conformance mode?</font><br><font size=2 face="sans-serif"> Fred: They can
do whatever they want.</font><br><font size=2 face="sans-serif"> David: At least some processors
(Ex. 68000 and x87) like wide returns to use registers and do it. They
would object to having it forced to go to memory.</font><br><font size=2 face="sans-serif"> Aaron: If you don't know
if the wide representation is used or not is troubling.</font><br><font size=2 face="sans-serif"> Rajan: If you want to
force the type you can always cast with forces stripping the extra range
and precision.</font><br><font size=2 face="sans-serif"> Blaine: The question is
is the extra range visibly useful.</font><br><font size=2 face="sans-serif"> David: Since not everyone
can cast without going to memory and back, it is a performance hit for
them. It is really expensive to go to memory and back.</font><br><font size=2 face="sans-serif"> Fred: Integers can do
this too.</font><br><font size=2 face="sans-serif"> David: They generally
do, but they also generally have cast instructions (Larry: Assuming AND
works).</font><br><font size=2 face="sans-serif"> Blaine: It's weird for
_Bool since if you clear just a byte instead of a word it may have 1 bits
elsewhere.</font><br><font size=2 face="sans-serif"> Barry: How did it get
added to C99?</font><br><font size=2 face="sans-serif"> Fred: By my paper N1017
as stated in this paper.</font><br><font size=2 face="sans-serif"> Clark: This is an area
where there has been trash and whether we are continuing to thrash.</font><br><font size=2 face="sans-serif"> Blaine: The committee
has non-constant membership so can have non-constant decisions.</font><br><font size=2 face="sans-serif"> Clark: Why was this brought
up now?</font><br><font size=2 face="sans-serif"> Fred: To address Willem's
issue.</font><br><font size=2 face="sans-serif"> Clark: The other paper
(N1396) was explicitly for Annex F not the main body of the standard for
IEEE conformance.</font><br><font size=2 face="sans-serif"> David: Willem is a fixed
point expert who is only recently looking at floating point. That's why
this is coming up now.</font><br><font size=2 face="sans-serif"> Martin: Is this specific
to the return statement. Does it apply to other things too?</font><br><font size=2 face="sans-serif"> Fred: No, because elsewhere
FLT_EVAL_METHOD defines how it works elsewhere.</font><br><font size=2 face="sans-serif"> Larry: This is an ABI
issue.</font><br><font size=2 face="sans-serif"> Clark: This is not an
ABI issue, since it is about the representation, not the value.</font><br><font size=2 face="sans-serif"> Fred: It is an ABI issue
since the result is given via registers in some cases.</font><br><font size=2 face="sans-serif"> Martin: What happens if
you are returning a struct with more float members than registers. This
means some will have the extra range and precision (the members returned
in registers) and not in others (the ones that spilled into memory).</font><br><font size=2 face="sans-serif"> Blaine: We should use
the register keyword!</font><br><font size=2 face="sans-serif"> Fred: If the user wants
to strip the extra range they need a cast after each function call vs putting
the cast in the function before the return.</font><br><font size=2 face="sans-serif"> Rajan: There is cost to
adopting this proposal, but minimal if any benefit, we shouldn't do anything.
If it matters to the programmer, they can always use a cast to remove the
extra range and precision.</font><br><font size=2 face="sans-serif"> David: Willem is complaining
about the lack of a cross reference not that he wants to remove the extra
range and precision. The CFP paper addresses that already so we don't need
to scrape off the bits, especially for embedded systems which may not have
cache.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Straw poll: Do we want
to adopt N2172?</font><br><font size=2 face="sans-serif"> 2/11/0. We will
not adopt the paper. </font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> N2166: Evaluation formats</font><br><font size=2 face="sans-serif"> N2186 is taken as the
response and being added to SD3. This is the paper that we had Jim write
on our behalf to respond to Willem's paper (</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><br><font size=2 face="sans-serif"><b>DR's:</b></font><br><font size=2 face="sans-serif"> TS18661 (CFP) [N2149]</font><br><font size=2 face="sans-serif"> ---</font><br><font size=2 face="sans-serif"> DR5: Move to closed.</font><br><font size=2 face="sans-serif"> DR6: Move to closed.</font><br><font size=2 face="sans-serif"> DR7: Move to closed.</font><br><font size=2 face="sans-serif"> DR8: Move to closed.</font><br><font size=2 face="sans-serif"> DR10: Move to closed.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> DR9: Move to review.</font><br><font size=2 face="sans-serif"> DR11: Move to review.</font><br><font size=2 face="sans-serif"> DR12: Move to review.</font><br><font size=2 face="sans-serif"> David: Prefer to
have the first to changes with regards to "can be interpreted as"
being a note/footnote.</font><br><font size=2 face="sans-serif"> Clark: I makes
sense the way it is too. Can keep it as.</font><br><font size=2 face="sans-serif"> DR13: Move to review.</font><br><font size=2 face="sans-serif"> DR14: Move to review.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> CFP DR15: N2171: Characteristic
macros for non-arithmetic formats</font><br><font size=2 face="sans-serif"> Agree.</font><br><font size=2 face="sans-serif"> ---</font><br><font size=2 face="sans-serif"> Blaine: The second change
after the "except" seems to need it's own sentence.</font><br><font size=2 face="sans-serif"> Make the suggested TC
into a proposed TC.</font><br><font size=2 face="sans-serif"> Leave in open.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> CFP DR16: N2178: tgmath cbrt
macro</font><br><font size=2 face="sans-serif"> Agree.</font><br><font size=2 face="sans-serif"> ---</font><br><font size=2 face="sans-serif"> Some messages in the reflector.</font><br><font size=2 face="sans-serif"> Clark: Feels weird since
it is updating an example, and also being overspecified.</font><br><font size=2 face="sans-serif"> Jens: The (X) should be
moved outside of the generic statement.</font><br><font size=2 face="sans-serif"> Clark: The reason for
this change is to show how the static rounding modes affect standard library
functions.</font><br><font size=2 face="sans-serif"> This change is
not necessary.</font><br><font size=2 face="sans-serif"> Rajan: Why is it not necessary?</font><br><font size=2 face="sans-serif"> Clark: The use of a tgmath
macro is affected by the static rounding mode. Using the address of the
function may not follow the static rounding mode. Don't like the original
fix, nor the fix to the fix. Seems to be going further in the wrong direction.
There are aspects with interactions with tgmath and static rounding modes
that need thought, but should go back to the drawing board.</font><br><font size=2 face="sans-serif"> Blaine: Maybe have a simpler
example. Perhaps don't use _Generic in the example.</font><br><font size=2 face="sans-serif"> Clark: They are saying
the example of _Generic needs to be fixed.</font><br><font size=2 face="sans-serif"> Larry: Having the (X)
in the definition can cause compiler diagnostics due to type mismatch.</font><br><font size=2 face="sans-serif"> Fred: Can be editorial
to move the (X) outside.</font><br><font size=2 face="sans-serif"> Clark: This is the third
attempted fix and it bothers me that this is for an example.</font><br><font size=2 face="sans-serif"> There are a variety
of issues with this.</font><br><font size=2 face="sans-serif"> Rajan: I would love to
see a paper showing the issues so we can handle them.</font><br><font size=2 face="sans-serif"> Clark: I can join a telecon,
but probably not the next one.</font><br><font size=2 face="sans-serif"> I am good with
this being a DR, but not a proposed TC.</font><br><font size=2 face="sans-serif"> The issue is still unresolved
and Clark will attend one of the meetings to help resolve it.</font><br><font size=2 face="sans-serif"> *AI* Rajan to invite Clark
specifically to the meetings (not just in the reflector) to help resolve
this issue.</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><BR>