[Cfp-interest] WG14 Meeting summary for CFP

Thu Nov 2 07:36:01 PDT 2017

Attendees: Rajan, Fred

Papers:
  N2172: Return and extra precision
    The ABI can stay the same. They just have to go through the knothole.
    Blaine: Seems reasonable other than inline functions.
    Fred: That means if the user uses inline or not can give different 
results on computations.
    David: Often people are encouraged to use static inline vs macros. 
Losing the extra range and precision would hurt them.
    Barry: What do compilers do right now in standard conformance mode?
      Fred: They can do whatever they want.
    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.
    Aaron: If you don't know if the wide representation is used or not is 
troubling.
    Rajan: If you want to force the type you can always cast with forces 
stripping the extra range and precision.
    Blaine: The question is is the extra range visibly useful.
    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.
    Fred: Integers can do this too.
    David: They generally do, but they also generally have cast 
instructions (Larry: Assuming AND works).
    Blaine: It's weird for _Bool since if you clear just a byte instead of 
a word it may have 1 bits elsewhere.
    Barry: How did it get added to C99?
    Fred: By my paper N1017 as stated in this paper.
    Clark: This is an area where there has been trash and whether we are 
continuing to thrash.
    Blaine: The committee has non-constant membership so can have 
non-constant decisions.
    Clark: Why was this brought up now?
    Fred: To address Willem's issue.
    Clark: The other paper (N1396) was explicitly for Annex F not the main 
body of the standard for IEEE conformance.
    David: Willem is a fixed point expert who is only recently looking at 
floating point. That's why this is coming up now.
    Martin: Is this specific to the return statement. Does it apply to 
other things too?
    Fred: No, because elsewhere FLT_EVAL_METHOD defines how it works 
elsewhere.
    Larry: This is an ABI issue.
    Clark: This is not an ABI issue, since it is about the representation, 
not the value.
    Fred: It is an ABI issue since the result is given via registers in 
some cases.
    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).
    Blaine: We should use the register keyword!
    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.
    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.
    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.
 
    Straw poll: Do we want to adopt N2172?
      2/11/0. We will not adopt the paper. 
 
  N2166: Evaluation formats
    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 (
http://wiki.edg.com/pub/CFP/WebHome/WW_evaluation_formats-20171007.pdf)

DR's:
  TS18661 (CFP) [N2149]
    ---
    DR5: Move to closed.
    DR6: Move to closed.
    DR7: Move to closed.
    DR8: Move to closed.
    DR10: Move to closed.
 
    DR9: Move to review.
    DR11: Move to review.
    DR12: Move to review.
      David: Prefer to have the first to changes with regards to "can be 
interpreted as" being a note/footnote.
      Clark: I makes sense the way it is too. Can keep it as.
    DR13: Move to review.
    DR14: Move to review.
 
  CFP DR15: N2171: Characteristic macros for non-arithmetic formats
    Agree.
    ---
    Blaine: The second change after the "except" seems to need it's own 
sentence.
    Make the suggested TC into a proposed TC.
    Leave in open.
 
  CFP DR16: N2178: tgmath cbrt macro
    Agree.
    ---
    Some messages in the reflector.
    Clark: Feels weird since it is updating an example, and also being 
overspecified.
    Jens: The (X) should be moved outside of the generic statement.
    Clark: The reason for this change is to show how the static rounding 
modes affect standard library functions.
      This change is not necessary.
    Rajan: Why is it not necessary?
    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.
    Blaine: Maybe have a simpler example. Perhaps don't use _Generic in 
the example.
    Clark: They are saying the example of _Generic needs to be fixed.
    Larry: Having the (X) in the definition can cause compiler diagnostics 
due to type mismatch.
    Fred: Can be editorial to move the (X) outside.
    Clark: This is the third attempted fix and it bothers me that this is 
for an example.
      There are a variety of issues with this.
    Rajan: I would love to see a paper showing the issues so we can handle 
them.
    Clark: I can join a telecon, but probably not the next one.
      I am good with this being a DR, but not a proposed TC.
    The issue is still unresolved and Clark will attend one of the 
meetings to help resolve it.
    *AI* Rajan to invite Clark specifically to the meetings (not just in 
the reflector) to help resolve this issue.

Regards,

Rajan Bhakta
z/OS XL C/C++ Compiler Technical Architect
ISO C Standards Representative for Canada
C Compiler Development
Contact: rbhakta at us.ibm.com, Rajan Bhakta/Houston/IBM


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20171102/4c6961fc/attachment-0003.html