<font size=2 face="sans-serif">IEEE-754 2008 binding to C: Fall 2012 JTC1/SC22/WG14
meeting minute notes (2012/10/23):</font>
<br><font size=2 face="sans-serif">Presenter: Jim Thomas</font>
<br><font size=2 face="sans-serif">Other IEEE study group members present:
Fred Tydeman, Rajan Bhakta, Marius Cornea</font>
<br><font size=2 face="sans-serif">Note taker: Rajan Bhakta</font>
<br>
<br><font size=2 face="sans-serif"><b>TS Part 1:</b></font>
<br><font size=2 face="sans-serif">Going over differences from the Kona
meeting.</font>
<br><font size=2 face="sans-serif">Goal is for a document ready for detailed
review for the next meeting.</font>
<br><font size=2 face="sans-serif">Posted on IEEE-754 reflector as well
for comments.</font>
<br>
<br><font size=2 face="sans-serif">Conformance macro change by adding BFP</font>
<br><font size=2 face="sans-serif"> Tom Plum: Should we change our
date format (201ymm form) to the draft date form to avoid the TC for C11
issue that happened.</font>
<br><font size=2 face="sans-serif"> Barry Hedquist: It could still
be the wrong number if we forget at the end again.</font>
<br><font size=2 face="sans-serif"> Tom: Disagree. It is "right"
since it reflects the draft.</font>
<br><font size=2 face="sans-serif"> John Benito: It would be better
than text. This would be a number. So usable and "righter" than
yyyymm.</font>
<br><font size=2 face="sans-serif"> Jim's call.</font>
<br><font size=2 face="sans-serif"> Jim Thomas: If we put a date,
someone may start using that date.</font>
<br><font size=2 face="sans-serif">Conformance for freestanding implementations</font>
<br><font size=2 face="sans-serif"> No comments.</font>
<br><font size=2 face="sans-serif">Want macro</font>
<br><font size=2 face="sans-serif"> Tom: Keep it simple</font>
<br><font size=2 face="sans-serif">Cannonical-ness</font>
<br><font size=2 face="sans-serif"> No comments.</font>
<br><font size=2 face="sans-serif">Encoding usage</font>
<br><font size=2 face="sans-serif"> No comments (minor clarification
question from Robert Seacord on need).</font>
<br><font size=2 face="sans-serif">Reference column in table</font>
<br><font size=2 face="sans-serif"> Clark Nelson: Is the plan to
remove annex F and G?</font>
<br><font size=2 face="sans-serif"> Jim: It updates them, following
the form of other TR/TS's.</font>
<br><font size=2 face="sans-serif"> John: We've done the same form
for the Embedded C TR.</font>
<br><font size=2 face="sans-serif">Constant rounding direction</font>
<br><font size=2 face="sans-serif"> No comments.</font>
<br><font size=2 face="sans-serif">Allow SNaNs macro</font>
<br><font size=2 face="sans-serif"> No comments.</font>
<br><font size=2 face="sans-serif">Renamed macros for integer</font>
<br><font size=2 face="sans-serif"> No comments.</font>
<br><font size=2 face="sans-serif">intmax_t types</font>
<br><font size=2 face="sans-serif"> No comments.</font>
<br><font size=2 face="sans-serif">Sample implementation code SNaN issues
(round function)</font>
<br><font size=2 face="sans-serif"> No comments.</font>
<br><font size=2 face="sans-serif">fmax/fmaxmag sample implementation</font>
<br><font size=2 face="sans-serif"> No comments.</font>
<br><font size=2 face="sans-serif">iseqsig macro</font>
<br><font size=2 face="sans-serif"> No comments.</font>
<br><font size=2 face="sans-serif">iszero</font>
<br><font size=2 face="sans-serif"> No comments.</font>
<br><font size=2 face="sans-serif">tgmath header</font>
<br><font size=2 face="sans-serif"> No comments.</font>
<br>
<br><font size=2 face="sans-serif">General questions/comments:</font>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">Jim: The treatment of SNaNs doesn't
change control flow. It raises a flag. Some implementation may add an extension
to trap on these.</font>
<br><font size=2 face="sans-serif">Tom: I want a way to avoid traps for
SNaNs.</font>
<br><font size=2 face="sans-serif">Jim: Only an extension would give this.
Default and standard C code would not trap.</font>
<br><font size=2 face="sans-serif">P.J. Plauger: FE_SET_EXCEPT wouldn't
cause a trap?</font>
<br><font size=2 face="sans-serif">Jim: No, it just sets a flag/raises
a flag. It doesn't actually trap.</font>
<br><font size=2 face="sans-serif">P.J.: FE_SET_EXCEPT can set a trap according
to the IEEE-754 standard.</font>
<br><font size=2 face="sans-serif">Jim: That is in the IEEE standard, not
in the C standard.</font>
<br><font size=2 face="sans-serif">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?</font>
<br><font size=2 face="sans-serif">No "no"'s. We will go forward
with this document.</font>
<br><font size=2 face="sans-serif">Jim: Do we want a formal review?</font>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">No support for reviewing this in the
C committee.</font>
<br>
<br><font size=2 face="sans-serif"><b>TS Part 2:</b></font>
<br><font size=2 face="sans-serif">Supersedes the decimal floating point
TR</font>
<br><font size=2 face="sans-serif">Going over the differences from the
TR</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">Marius: The DFP TR being moved into
the standard was discussed in the C++ meeting last week.</font>
<br><font size=2 face="sans-serif">Benito: It would be better to update
their TR before putting it into the standard.</font>
<br><font size=2 face="sans-serif">Bill Seymour: I can bring this up in
C++ and keep an eye on this.</font>
<br><font size=2 face="sans-serif">Clark: There has been zero discussion
amongst the full C++ committee to bring DFP TR into the full standard.</font>
<br><font size=2 face="sans-serif">Clark: The response in C++ from the
notes sent out were lukewarm at best. Don't assume the floating point updated
binding will happen.</font>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">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?</font>
<br><font size=2 face="sans-serif">Jim: We're sending off a proposal for
a 5 part TS. This is the second part.</font>
<br><font size=2 face="sans-serif">Marius: I see more interest in DFP lately
but not huge. Mostly for financial computation.</font>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">Marius: We have an open source version
that supports everything.</font>
<br><font size=2 face="sans-serif">Seymour: Wouldn't financial applications
want more fixed point rather than floating point?</font>
<br><font size=2 face="sans-serif">Jim: IEEE semantics allow you to do
floating point as if it was fixed point.</font>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">Jim: A lot of the decimal transcendental
functions are implemented in binary underneath.</font>
<br><font size=2 face="sans-serif">Plaguer: This is a warning for the innocent
person to replace BFP with DFP is that there are much larger error bars.</font>
<br>
<br><font size=2 face="sans-serif">Jim: Added in all the IEC 60559 features.
The old TR only did what C89/99 had and no extensions.</font>
<br>
<br><font size=2 face="sans-serif">Same conformance and want macro as the
TR</font>
<br><font size=2 face="sans-serif"> No comments.</font>
<br><font size=2 face="sans-serif">Conformance to part 2 requires conformance
to part 1</font>
<br><font size=2 face="sans-serif"> Prosser: You expect all parts
to depend on previous ones?</font>
<br><font size=2 face="sans-serif"> Jim: I expect the next three
will want parts of each.</font>
<br><font size=2 face="sans-serif"> Prosser: But the major split
is only DFP or not?</font>
<br><font size=2 face="sans-serif"> Jim: Yes, we haven't written
the other parts, but I think that will be the case.</font>
<br><font size=2 face="sans-serif"> Blaine Garst: I prefer keeping
the same form macros as Part 1.</font>
<br><font size=2 face="sans-serif"> Clark: Didn't say anything about
why part 1 is needed.</font>
<br><font size=2 face="sans-serif"> 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.</font>
<br><font size=2 face="sans-serif"> Barry: Can we say which parts
in 2 require which parts in part 1?</font>
<br><font size=2 face="sans-serif"> Jim: We could but it could make
a very complicated part 2</font>
<br><font size=2 face="sans-serif"> Benito: Could you separate out
the common parts (part 0)?</font>
<br><font size=2 face="sans-serif"> Jim: We could but it would have
been a radical departure from annex F.</font>
<br><font size=2 face="sans-serif"> 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.</font>
<br><font size=2 face="sans-serif"> Jim: It is stronger than what
we think it is. Someone could do part 2.</font>
<br><font size=2 face="sans-serif"> Tom: This pushes for a part 0
again since it seems what we say is you have to have IEEE BFP.</font>
<br><font size=2 face="sans-serif"> 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.</font>
<br><font size=2 face="sans-serif"> Jim: This is a binding to the
IEEE floating point standard.</font>
<br><font size=2 face="sans-serif"> Clark: There might be value in
having a quick'n'dirty form like BFP (C Standard vs Annex F).</font>
<br><font size=2 face="sans-serif"> 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.</font>
<br><font size=2 face="sans-serif"> Marius: The IEEE standard allows
you have DFP without BFP or vice versa.</font>
<br><font size=2 face="sans-serif"> Blaine: What is the technical
requirement of requiring part 1?</font>
<br><font size=2 face="sans-serif"> Jim: It's an expediency issue.
To make the document simpler, more comprehensible and maintainable.</font>
<br><font size=2 face="sans-serif"> 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.</font>
<br><font size=2 face="sans-serif"> Jim: It's not just what we're
adding. There is stuff in Annex F already there.</font>
<br><font size=2 face="sans-serif"> Rajan: IBM has this type and
we are OK with this.</font>
<br><font size=2 face="sans-serif"> Benito: Is the major concern
that this is hard to maintain or that there is issues with Annex F?</font>
<br><font size=2 face="sans-serif"> Jim: Annex F has concepts that
apply to DFP that are not type dependent.</font>
<br><font size=2 face="sans-serif"> Benito: We can change Annex F
in the TS</font>
<br><font size=2 face="sans-serif"> Clark: What parts of Annex F
are needed for DFP?</font>
<br><font size=2 face="sans-serif"> Jim: Exception handling is an
example.</font>
<br><font size=2 face="sans-serif"> 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.</font>
<br><font size=2 face="sans-serif"> ***Still an issue that the group
should look into. Most people were not comfortable with requiring part
1.</font>
<br><font size=2 face="sans-serif"> 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.</font>
<br><font size=2 face="sans-serif"> 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.</font>
<br><font size=2 face="sans-serif"> Benito/Barry: This is exactly
what we think would be useful.</font>
<br><font size=2 face="sans-serif">TRUE_MIN macro name change</font>
<br><font size=2 face="sans-serif"> No comments.</font>
<br><font size=2 face="sans-serif">Operation binding</font>
<br><font size=2 face="sans-serif"> No comments.</font>
<br><font size=2 face="sans-serif">May or may not raise exceptions</font>
<br><font size=2 face="sans-serif"> Are casts and assignments the
same?</font>
<br><font size=2 face="sans-serif"> Keaton: What is the difference
we have for assignments and casts?</font>
<br><font size=2 face="sans-serif"> Jim: Implicit conversions raise
exceptions, so assignments and parameter passing would raise exceptions
while casts wouldn't.</font>
<br><font size=2 face="sans-serif"> Keaton: The security group is
using this by saying explicit casts implies intent.</font>
<br><font size=2 face="sans-serif"> Clark: Every compiler will diagnose
implicit conversions but not explicit conversions. IEEE has this as a recommendation.
We should do the same.</font>
<br><font size=2 face="sans-serif"> Jim: No one is saying we are
violating existing C practice by making this a recommendation.</font>
<br><font size=2 face="sans-serif"> Prosser: 3 types: Explicit cast,
assignment, parameter passing (like initialization). Like const qualified
parameters. We need to consider initialization here.</font>
<br><font size=2 face="sans-serif"> Jim: This is for conversions
(float to int).</font>
<br><font size=2 face="sans-serif"> Prosser: Assuming you are assigning
3.14 to an integer automatic at runtime. What does IEEE say?</font>
<br><font size=2 face="sans-serif"> Jim: Whatever the language says
is an implicit conversion.</font>
<br><font size=2 face="sans-serif"> Prosser: At least one other issue
(not just assignments and casts).</font>
<br><font size=2 face="sans-serif"> Jim: The recommendation would
be in terms of conversions, not assignments and casts.</font>
<br><font size=2 face="sans-serif">Decimal 64 pragma removal:</font>
<br><font size=2 face="sans-serif"> No comments.</font>
<br><font size=2 face="sans-serif">Suffix for double constants removal:</font>
<br><font size=2 face="sans-serif"> No comments.</font>
<br><font size=2 face="sans-serif">Want macros:</font>
<br><font size=2 face="sans-serif"> ***Tom: The standard could define
both forms.</font>
<br><font size=2 face="sans-serif"> Jim: Would you deprecate the
old one?</font>
<br><font size=2 face="sans-serif"> Tom: You could.</font>
<br><font size=2 face="sans-serif">Decimal versions of SNaNs</font>
<br><font size=2 face="sans-serif"> No comments.</font>
<br><font size=2 face="sans-serif">Radix of generic floating types:</font>
<br><font size=2 face="sans-serif"> Prosser: I recall some part of
the standard calls out radix 10.</font>
<br><font size=2 face="sans-serif"> 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.</font>
<br><font size=2 face="sans-serif"> Blaine: You list "real"
and redefine it to "generic". Do you intend to replace the "real"
type into generic?</font>
<br><font size=2 face="sans-serif"> Jim: It should list all the places.
It's part of the TR.</font>
<br><font size=2 face="sans-serif"> Fred: "real" is the
union of generics and decimal.</font>
<br><font size=2 face="sans-serif"> Blaine: I will send a comment
to you guys.</font>
<br><font size=2 face="sans-serif"> Jim: We are only adding the decimal
types to the real types.</font>
<br><font size=2 face="sans-serif">Decimal re-encoding functions:</font>
<br><font size=2 face="sans-serif"> Prosser: When picking up some
non-printable data from some external source, you have to run it through
these functions to use them?</font>
<br><font size=2 face="sans-serif"> Jim: No, this is just for data
in encodings in forms that the implementation uses.</font>
<br><font size=2 face="sans-serif"> Prosser: The IEEE for BFP talks
about the internals. It doesn't do the UTF-8 equivalent like these functions
seem to do.</font>
<br><font size=2 face="sans-serif"> Jim: This is below the level
of abstraction for the operations.</font>
<br><font size=2 face="sans-serif"> Prosser: Is this a third form?
Or will it be one of these two?</font>
<br><font size=2 face="sans-serif"> Jim: It will be one of these
two, but the spec does not say this.</font>
<br><font size=2 face="sans-serif"> Tom: What are the two forms DPD,
BID like?</font>
<br><font size=2 face="sans-serif"> 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.</font>
<br><font size=2 face="sans-serif"> Clark: DPD is BCD but condensed.
BID is base 2. DPD is better for hardware, BID is better for software.</font>
<br><font size=2 face="sans-serif">a/A printf formatting edge cases</font>
<br><font size=2 face="sans-serif"> No comments.</font>
<br><font size=2 face="sans-serif">tgmath for decimal</font>
<br><font size=2 face="sans-serif"> No comments.</font>
<br><font size=2 face="sans-serif">quantum exponents</font>
<br><font size=2 face="sans-serif"> No comments.</font>
<br><font size=2 face="sans-serif">optimization</font>
<br><font size=2 face="sans-serif"> No comments.</font>
<br>
<br><font size=2 face="sans-serif">General questions/comments:</font>
<br><font size=2 face="sans-serif"> Blaine: 60559 does not talk about
these.</font>
<br><font size=2 face="sans-serif"> Jim: It does.</font>
<br><font size=2 face="sans-serif"> Blaine: Does it talk about preferred
exponents?</font>
<br><font size=2 face="sans-serif"> Jim: It is there, but we had
to extend what 60559 said to cover all the operations in C.</font>
<br><font size=2 face="sans-serif"> 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.</font>
<br><font size=2 face="sans-serif"> Fred: Is there an issue about
the CFP wiki being opened up?</font>
<br><font size=2 face="sans-serif"> Benito: I'm not asking for this.
We'll post documents in a different place, etc. and to not disrupt progress.</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@ca.ibm.com, Rajan Bhakta/Toronto/IBM<br>
Telephone: (905) 413-3995</font>