[Cfp-interest] Raw WG14 meeting notes for the CFP presentations

[Rajan Bhakta]

IEEE-754 2008 binding to C: Fall 2012 JTC1/SC22/WG14 meeting minute notes 
(2012/10/23):
Presenter: Jim Thomas
Other IEEE study group members present: Fred Tydeman, Rajan Bhakta, Marius 
Cornea
Note taker: Rajan Bhakta

TS Part 1:
Going over differences from the Kona meeting.
Goal is for a document ready for detailed review for the next meeting.
Posted on IEEE-754 reflector as well for comments.

Conformance macro change by adding BFP
  Tom Plum: Should we change our date format (201ymm form) to the draft 
date form to avoid the TC for C11 issue that happened.
  Barry Hedquist: It could still be the wrong number if we forget at the 
end again.
  Tom: Disagree. It is "right" since it reflects the draft.
  John Benito: It would be better than text. This would be a number. So 
usable and "righter" than yyyymm.
    Jim's call.
  Jim Thomas: If we put a date, someone may start using that date.
Conformance for freestanding implementations
  No comments.
Want macro
  Tom: Keep it simple
Cannonical-ness
  No comments.
Encoding usage
  No comments (minor clarification question from Robert Seacord on need).
Reference column in table
  Clark Nelson: Is the plan to remove annex F and G?
  Jim: It updates them, following the form of other TR/TS's.
  John: We've done the same form for the Embedded C TR.
Constant rounding direction
  No comments.
Allow SNaNs macro
  No comments.
Renamed macros for integer
  No comments.
intmax_t types
  No comments.
Sample implementation code SNaN issues (round function)
  No comments.
fmax/fmaxmag sample implementation
  No comments.
iseqsig macro
  No comments.
iszero
  No comments.
tgmath header
  No comments.

General questions/comments:
Tom: Can you write an interrupt service to change SNaN to QNaNs? i.e. If a 
group doesn't want to support SNaN's can they avoid them? The application 
group can be different from the implementer group.
Jim: The treatment of SNaNs doesn't change control flow. It raises a flag. 
Some implementation may add an extension to trap on these.
Tom: I want a way to avoid traps for SNaNs.
Jim: Only an extension would give this. Default and standard C code would 
not trap.
P.J. Plauger: FE_SET_EXCEPT wouldn't cause a trap?
Jim: No, it just sets a flag/raises a flag. It doesn't actually trap.
P.J.: FE_SET_EXCEPT can set a trap according to the IEEE-754 standard.
Jim: That is in the IEEE standard, not in the C standard.
Benito: The layout of the document is wrong if we want to go forward with 
this document. Is the committee OK to use this as a proposal for a work 
item with editorial changes to the layout?
No "no"'s. We will go forward with this document.
Jim: Do we want a formal review?
Benito: We are reviewing it now. This is different from Secure Coding 
since it was asked for. If people want a review on this, we will have one.
No support for reviewing this in the C committee.

TS Part 2:
Supersedes the decimal floating point TR
Going over the differences from the TR

Tom Plum: C++ liaison issue. We did simultaneous for the decimal TR. Do we 
have one? I am not interested in being involved, but we should get the 
right people involved.
Marius: The DFP TR being moved into the standard was discussed in the C++ 
meeting last week.
Benito: It would be better to update their TR before putting it into the 
standard.
Bill Seymour: I can bring this up in C++ and keep an eye on this.
Clark: There has been zero discussion amongst the full C++ committee to 
bring DFP TR into the full standard.
Clark: The response in C++ from the notes sent out were lukewarm at best. 
Don't assume the floating point updated binding will happen.
Tom: The previous Kona meeting Mike Coleshaw (sp?) offered to present DFP 
on Friday afternoon, and at that time, every single person there in WG14 
stayed for the presentation instead of taking the afternoon off to visit 
the beach.
Tom: What if DFP becomes the preferred mechanism for doing floating point 
work and BFP falls by the wayside. It seems back in 2007 it seemed more 
important then than now in 2012. How important will this be for floating 
point work now? Is this still an area of intense interest?
Jim: We're sending off a proposal for a 5 part TS. This is the second 
part.
Marius: I see more interest in DFP lately but not huge. Mostly for 
financial computation.
Dave Prosser: If this was in the standard last year it would have been 
more convenient. The DFP TR didn't help with that for Bloomberg. The bulk 
of people there didn't even know there was a new standard. I have to wait 
for all the vendors for all the compilers to add support for the new 
standard before we use new features.
Jacob Navia: I tried to use this in my system, but seeing the copyright 
IBM scared me off using the code. I can't add everything myself.
Marius: We have an open source version that supports everything.
Seymour: Wouldn't financial applications want more fixed point rather than 
floating point?
Jim: IEEE semantics allow you to do floating point as if it was fixed 
point.
Plauger: I was working on this in the past but realized there was no 
demand for it. We got far enough to see that it is hard to get right 
results since the jitter kills you compared to BFP. Every single math 
function resulted in playing games to keep the best precision. Due to 
this, I dropped it and never had a customer ask for it.
Jim: A lot of the decimal transcendental functions are implemented in 
binary underneath.
Plaguer: This is a warning for the innocent person to replace BFP with DFP 
is that there are much larger error bars.

Jim: Added in all the IEC 60559 features. The old TR only did what C89/99 
had and no extensions.

Same conformance and want macro as the TR
  No comments.
Conformance to part 2 requires conformance to part 1
  Prosser: You expect all parts to depend on previous ones?
  Jim: I expect the next three will want parts of each.
  Prosser: But the major split is only DFP or not?
  Jim: Yes, we haven't written the other parts, but I think that will be 
the case.
  Blaine Garst: I prefer keeping the same form macros as Part 1.
  Clark: Didn't say anything about why part 1 is needed.
  Jim: We have a lot of concepts like returns, NaNs, etc. that we talk 
about in part 1 which we could have replicated in part 2 to avoid the 
requirement of need for part 1, but it introduces sync issues. An 
implementer could say they followed part 2 but not saying they conformed.
  Barry: Can we say which parts in 2 require which parts in part 1?
  Jim: We could but it could make a very complicated part 2
  Benito: Could you separate out the common parts (part 0)?
  Jim: We could but it would have been a radical departure from annex F.
  Tom: The net is if you want a conforming DFP, you have to have BFP. We 
are ruling out the idea of having their own BFP like Cray and Digital. 
This is why IEEE BFP was an annex and not part of the standard. As far as 
I know this is a reasonable thing to say, but I wanted to get it out on 
the table.
  Jim: It is stronger than what we think it is. Someone could do part 2.
  Tom: This pushes for a part 0 again since it seems what we say is you 
have to have IEEE BFP.
  Clark: Not concerned with having BFP formats match. But what does 
concern me is that some people are very concerned with reproducibility and 
corner cases, etc. while others just want an answer and don't care about 
the details. This specification disparages the crowd that just want an 
answer.
  Jim: This is a binding to the IEEE floating point standard.
  Clark: There might be value in having a quick'n'dirty form like BFP (C 
Standard vs Annex F).
  Jim: The TR talks about this in the introduction. The TR says that since 
this is a new thing, they consciously decided to follow IEEE since there 
was no legacy.
  Marius: The IEEE standard allows you have DFP without BFP or vice versa.
  Blaine: What is the technical requirement of requiring part 1?
  Jim: It's an expediency issue. To make the document simpler, more 
comprehensible and maintainable.
  Blaine: Do we think someone like FPGA users would want only DFP without 
BFP? They could not legally say they conform to the standard since they 
don't have BFP.
  Jim: It's not just what we're adding. There is stuff in Annex F already 
there.
  Rajan: IBM has this type and we are OK with this.
  Benito: Is the major concern that this is hard to maintain or that there 
is issues with Annex F?
  Jim: Annex F has concepts that apply to DFP that are not type dependent.
  Benito: We can change Annex F in the TS
  Clark: What parts of Annex F are needed for DFP?
  Jim: Exception handling is an example.
  David Keaton: If vendors are OK with this, then maybe we should just add 
a note to the spec. Note that this happened for SIMD where they didn't 
follow the spec exactly.
  ***Still an issue that the group should look into. Most people were not 
comfortable with requiring part 1.
  Benito: The naming is going to be an issue. To keep compatibility with 
the TR would result in parts 1,3,4,5 having one form and part 2 having 
another.
  Rajan: We could reference parts of Part 1 as requirements in the "as if" 
form instead of saying all of Part 1 is required. This may result in 
changing grouping of Part 1 still.
  Benito/Barry: This is exactly what we think would be useful.
TRUE_MIN macro name change
  No comments.
Operation binding
  No comments.
May or may not raise exceptions
  Are casts and assignments the same?
  Keaton: What is the difference we have for assignments and casts?
  Jim: Implicit conversions raise exceptions, so assignments and parameter 
passing would raise exceptions while casts wouldn't.
  Keaton: The security group is using this by saying explicit casts 
implies intent.
  Clark: Every compiler will diagnose implicit conversions but not 
explicit conversions. IEEE has this as a recommendation. We should do the 
same.
  Jim: No one is saying we are violating existing C practice by making 
this a recommendation.
  Prosser: 3 types: Explicit cast, assignment, parameter passing (like 
initialization). Like const qualified parameters. We need to consider 
initialization here.
  Jim: This is for conversions (float to int).
  Prosser: Assuming you are assigning 3.14 to an integer automatic at 
runtime. What does IEEE say?
  Jim: Whatever the language says is an implicit conversion.
  Prosser: At least one other issue (not just assignments and casts).
  Jim: The recommendation would be in terms of conversions, not 
assignments and casts.
Decimal 64 pragma removal:
  No comments.
Suffix for double constants removal:
  No comments.
Want macros:
  ***Tom: The standard could define both forms.
  Jim: Would you deprecate the old one?
  Tom: You could.
Decimal versions of SNaNs
  No comments.
Radix of generic floating types:
  Prosser: I recall some part of the standard calls out radix 10.
  Jim: frexp for generic types has a built-in bias for power of two radix. 
Radix 10 would have an inexact result. If we have to consider 10, there is 
some special specification we have to do.
  Blaine: You list "real" and redefine it to "generic". Do you intend to 
replace the "real" type into generic?
  Jim: It should list all the places. It's part of the TR.
  Fred: "real" is the union of generics and decimal.
  Blaine: I will send a comment to you guys.
  Jim: We are only adding the decimal types to the real types.
Decimal re-encoding functions:
  Prosser: When picking up some non-printable data from some external 
source, you have to run it through these functions to use them?
  Jim: No, this is just for data in encodings in forms that the 
implementation uses.
  Prosser: The IEEE for BFP talks about the internals. It doesn't do the 
UTF-8 equivalent like these functions seem to do.
  Jim: This is below the level of abstraction for the operations.
  Prosser: Is this a third form? Or will it be one of these two?
  Jim: It will be one of these two, but the spec does not say this.
  Tom: What are the two forms DPD, BID like?
  Jim: It's like the big-endian/little-endian issue. Different companies 
had different ideas on how to encode these decimals. In some contexts one 
representation was better and in others the other was better.
  Clark: DPD is BCD but condensed. BID is base 2. DPD is better for 
hardware, BID is better for software.
a/A printf formatting edge cases
  No comments.
tgmath for decimal
  No comments.
quantum exponents
  No comments.
optimization
  No comments.

General questions/comments:
  Blaine: 60559 does not talk about these.
  Jim: It does.
  Blaine: Does it talk about preferred exponents?
  Jim: It is there, but we had to extend what 60559 said to cover all the 
operations in C.
  Benito: We are going to ask for a new work item. This means study group 
meetings will cease and working group meetings will cover this. Ex. 
Documents available to everyone. Note that this means study group 
participants have to determine how they will participate. For USA people 
they need to be a part of INCITS. Benito and Jim can work this out between 
them.
  Fred: Is there an issue about the CFP wiki being opened up?
  Benito: I'm not asking for this. We'll post documents in a different 
place, etc. and to not disrupt progress.

Regards,

Rajan Bhakta
z/OS XL C/C++ Compiler Technical Architect
ISO C Standards Representative for Canada
C Compiler Development
Contact: rbhakta at ca.ibm.com, Rajan Bhakta/Toronto/IBM
Telephone: (905) 413-3995
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20121023/1994bf88/attachment-0001.html