<font size=2 face="sans-serif"> Attendees: Ian, Jim, Fred, David,
Mike, Marius, Rajan</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Last meeting action item: F.3
as a footnote - Done</font>
<br><font size=2 face="sans-serif"> Email sent on April 12th,
2013</font>
<br><font size=2 face="sans-serif"> Next meeting: June 13th, 2013,
12:00 EST, 9:00 AM PDT</font>
<br><font size=2 face="sans-serif"> Continuing with the Oracle
teleconference number</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Action items:</font>
<br><font size=2 face="sans-serif"> *AI*: Formatting and reference
changes made to part 1 have to be made to part 2</font>
<br><font size=2 face="sans-serif"> *AI*: Jim to send an email
to WG14 asking for the one term change of "generic" to "traditional".
Can also list the terms we rejected.</font>
<br><font size=2 face="sans-serif"> *AI*: Mike to respond
to Jim's reset email</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Next C pre-meeting mailing is
September 2nd, 2013</font>
<br><font size=2 face="sans-serif"> We need to have any documents
we want to be discussed at the C meeting in the mailing at that time</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Part 1:</font>
<br><font size=2 face="sans-serif"> Made all changes from
the comments submitted + some other other editorial ones that were found</font>
<br><font size=2 face="sans-serif"> The final changed version
has been posted on the Wiki (n1711)</font>
<br><font size=2 face="sans-serif"> First ISO ballot (3 month)
will be on that document</font>
<br><font size=2 face="sans-serif"> We will need to
respond to comments on that ballot</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Part 2:</font>
<br><font size=2 face="sans-serif"> Comment by Willem regarding
changes made to Annex F by all the parts being confusing</font>
<br><font size=2 face="sans-serif"> Jim sent messages regarding
minimal changes in part 2 and part 3 to Annex F so this does not seem to
be too much of a problem</font>
<br><font size=2 face="sans-serif"> *AI*: Formatting and reference
changes made to part 1 have to be made to part 2</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Rajan's "quantum
exponent return type" email comments:</font>
<br><font size=2 face="sans-serif"> Fred: Why not use
long long?</font>
<br><font size=2 face="sans-serif"> Jim: _Decimal1024
would be larger than int64. We'd still have a built in limitation</font>
<br><font size=2 face="sans-serif"> Jim: Prefers option
2, though it wouldn't work for extended types for large exp vs significands.
We could make this a limitation on extended types</font>
<br><font size=2 face="sans-serif"> Jim: Also not compatible
to the decimal TR</font>
<br><font size=2 face="sans-serif"> Rajan: Maybe allow
the base cases (32, 64, 128) with int return types, and option 2 for larger
types</font>
<br><font size=2 face="sans-serif"> Mike: Or a new
name for the option 2 types with the basic ones (32, 64, 128) staying the
same as the TR so the common case is fast and easy to implement and the
new name for all types including extended ones. We may want to review other
functions to see if they can return a decimal type if int is constraining
it</font>
<br><font size=2 face="sans-serif"> Choose Option 2
with the mod suggested by Mike.</font>
<br><font size=2 face="sans-serif"> Naming:
Look at precedence like ilogb for something like dquantexpdN</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Part 3:</font>
<br><font size=2 face="sans-serif"> The term interchange type
caused a lot of confusion in the committee</font>
<br><font size=2 face="sans-serif"> Sentiment was not
to have types for interchange encodings, especially with the similar names
like _FloatN (with _Float16 as a special case)</font>
<br><font size=2 face="sans-serif"> Mike: Data only types
are not really fitting from the C point of view</font>
<br><font size=2 face="sans-serif"> Ian: I disagree with having
_Float16 as a mandatory type. Very few groups have hardware _Float16</font>
<br><font size=2 face="sans-serif"> Marius: Intel supports
_Float16 to some extent on 3rd gen Cores, limited to store now, with _Float32
evaluation</font>
<br><font size=2 face="sans-serif"> Jim: We can come back
to _Float16</font>
<br><font size=2 face="sans-serif"> Mike: Do we want to make
the arithmetic vs non-arithmetic distinction in C?</font>
<br><font size=2 face="sans-serif"> Rajan: Can we remove non-arithmetic
types?</font>
<br><font size=2 face="sans-serif"> *AI*: Mike to respond
to Jim's reset email</font>
<br><font size=2 face="sans-serif"> Jim's "reset part
3" email comments:</font>
<br><font size=2 face="sans-serif"> 5) generic ->
general</font>
<br><font size=2 face="sans-serif"> "general"
could mean any floating point type</font>
<br><font size=2 face="sans-serif"> How about classic,
traditional, standard, basic floating?</font>
<br><font size=2 face="sans-serif"> We could just not
use the term and list the types wherever we have generic</font>
<br><font size=2 face="sans-serif"> *AI*: Jim to send
an email to WG14 asking for the one term change of "generic"
to "traditional". Can also list the terms we rejected.</font>
<br><font size=2 face="sans-serif"> Can we not make
an allowance of float32/64 being float/double and macro definition of the
functions to allow the "traditional" type functions to be used
(can be done for extended types as well)</font>
<br><font size=2 face="sans-serif"> Would not
work with constant rounding modes and macro suppression</font>
<br><font size=2 face="sans-serif"> Require the new
types, but allow #defines, or make them optional to simplify Part 3, or
keep it the way it is with the encoding change?</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>