<html><body>
<p><font size="2" face="sans-serif">2013/11/13, 12:00 EST:</font><br>
<font size="2" face="sans-serif"> Attendees: Jim, Rajan, Fred, Mike, David, Marius, Ian, Walter Banks</font><br>
<font size="2" face="sans-serif"> </font><br>
<font size="2" face="sans-serif"><b> Old action items:</b></font><br>
<font size="2" face="sans-serif"> Jim: Part 2: Paragraph 12 should have (+, -, * or /) -> (+, -, * and /) - Done</font><br>
<font size="2" face="sans-serif"> Jim: Part 2: Page 8: Line 1: "are distinct types from float" -> "are distinct from the types float" - Done</font><br>
<font size="2" face="sans-serif"> Jim: Part 2: Page 32: The - sign seems to be in a different font and seems high. Try and make it look better. - Done</font><br>
<font size="2" face="sans-serif"> Jim: Part 2: Page 46: Change to split the table above into two 4 line chunks and use the individual rules per chunk. - Done</font><br>
<font size="2" face="sans-serif"> Jim: Part 2: Binding DFP applicable clauses in Annex F tighter to C11. Ex. Saying something like "An implementation that defines __STDC_IEC_559_DFP__ shall conform to the specifications in clauses ... in this annex" - Done</font><br>
<font size="2" face="sans-serif"> Jim: Look into using the Wiki as a backup for the documents in Word format. - Most current version has been put up. Keep this item open.</font><br>
<font size="2" face="sans-serif"> All: Review Part 3. Comments via email. - Done</font><br>
<font size="2" face="sans-serif"> All: Let Jim know of any changes to part 2 as soon as possible. - Done</font><br>
<br>
<font size="2" face="sans-serif"><b> Next Meeting:</b></font><br>
<font size="2" face="sans-serif"> December 12th, 2013, 12:00 EST, 9:00 PDT - Thursday</font><br>
<font size="2" face="sans-serif"> Same teleconference number.</font><br>
<font size="2" face="sans-serif"> </font><br>
<font size="2" face="sans-serif"><b> New action items:</b></font><br>
<font size="2" face="sans-serif"> Jim: Backup the documents in Word format. - Most current version has been put up. Keep this item open.</font><br>
<font size="2" face="sans-serif"> Current files: <a href="http://wiki.edg.com/twiki/pub/CFP/WebHome/cfp1.docx">http://wiki.edg.com/twiki/pub/CFP/WebHome/cfp1.docx</a></font><br>
<font size="2" face="sans-serif"> Current files: <a href="http://wiki.edg.com/twiki/pub/CFP/WebHome/cfp2.docx">http://wiki.edg.com/twiki/pub/CFP/WebHome/cfp2.docx</a></font><br>
<font size="2" face="sans-serif"> Current files: <a href="http://wiki.edg.com/twiki/pub/CFP/WebHome/cfp3.docx">http://wiki.edg.com/twiki/pub/CFP/WebHome/cfp3.docx</a></font><br>
<font size="2" face="sans-serif"> Current files: <a href="http://wiki.edg.com/twiki/pub/CFP/WebHome/cfp4.docx">http://wiki.edg.com/twiki/pub/CFP/WebHome/cfp4.docx</a></font><br>
<font size="2" face="sans-serif"> Note: Should also keep versions that are equivalent to PDF's.</font><br>
<font size="2" face="sans-serif"> Jim: Part 2: Will go with _Decimal32/64/128 ordering and Jim will follow up with Joseph to see if he agrees.</font><br>
<font size="2" face="sans-serif"> Jim: Part 2: Draft wording changes (based on Josephs email) regarding decimal vs generic radix 10 static rounding mode and we will review.</font><br>
<font size="2" face="sans-serif"> All: Part 2: A document will have to be delivered before the December meeting so please watch emails and respond quickly.</font><br>
<font size="2" face="sans-serif"> Jim: Part 1/2/3/4: Add a note regarding the a/b/c/... clause suffix meaning and reasoning for parts 2 on (since 1 is in ballot). Also check to see if this can be added in Part 1 as well.</font><br>
<font size="2" face="sans-serif"> Jim: Part 3: Try to use the math symbols for ceiling and floor instead of the words ceiling and floor.</font><br>
<font size="2" face="sans-serif"> Jim: Part 4: Look for opportunities for shortening function lists by removing suffixes.</font><br>
<font size="2" face="sans-serif"> Jim: Part 4: Send a note to the IEEE-754 group to get review of the draft from them.</font><br>
<font size="2" face="sans-serif"> Jim: Part 4: Remove the bold N in 5.3 function lists.</font><br>
<font size="2" face="sans-serif"> Jim: Part 4: Add in issue: We don't require conformance to part 3, and don't say _FloatNx (for example) must follow Part 3 so the functions are defined but are not the same as intended if an implemenatation has _FloatNx types but not Part 3 based.</font><br>
<font size="2" face="sans-serif"> Jim: Part 4: Pi functions: Drop the second "half-revolutions"</font><br>
<font size="2" face="sans-serif"> Jim: Part 4: atan2pi: Flag the description wording as an issue.</font><br>
<font size="2" face="sans-serif"> Jim: Part 4: atan2pi: Add in atan2pi has a domain error for both arguments being zero.</font><br>
<font size="2" face="sans-serif"> Jim: Part 4: log21p: Add in issue: It could be read as log 21 p instead of log2 1p.</font><br>
<font size="2" face="sans-serif"> Jim: Part 4: rsqrt: Need to add a domain error.</font><br>
<font size="2" face="sans-serif"> Jim: Part 4: compoundn: Add an issue: Why is it not an long long int?</font><br>
<font size="2" face="sans-serif"> </font><br>
<font size="2" face="sans-serif"><b> Part 1:</b></font><br>
<font size="2" face="sans-serif"> Sent off for ballot.</font><br>
<font size="2" face="sans-serif"> Final ballot stage.</font><br>
<font size="2" face="sans-serif"> If approved, it will be an official published ISO technical specification.</font><br>
<font size="2" face="sans-serif"> Ian: Can be considered for C14 (next C standard revision).</font><br>
<font size="2" face="sans-serif"> Can only change very minor editorial things (ex. bullet point style).</font><br>
<font size="2" face="sans-serif"> Document is in SCC (Canada) already, but not necessarily up for ballot yet.</font><br>
<font size="2" face="sans-serif"> </font><br>
<font size="2" face="sans-serif"><b> Part 2:</b></font><br>
<font size="2" face="sans-serif"> In WG14 review period. A step before the PDTS ballot (the first ballot).</font><br>
<font size="2" face="sans-serif"> A draft was sent to Joseph Myers (very productive reviewer) and has commented on it. Jim has replied on the WG14 reflector.</font><br>
<font size="2" face="sans-serif"> Arguing for ordering of symbols related to decimal. Ex. _Decimal64/32/128 is our current order and he wants _Decimal32/64/128.</font><br>
<font size="2" face="sans-serif"> Mike: 32 is not used and don't know any reason to use it. Use 128/64/32 instead.</font><br>
<font size="2" face="sans-serif"> Rajan: Parallels double/float/long double, or use small to large to allow adding new ones on later.</font><br>
<font size="2" face="sans-serif"> Mike: Any ordering is better than unordered.</font><br>
<font size="2" face="sans-serif"> *AI* Will go with _Decimal32/64/128 ordering and Jim will follow up with Joseph to see if he agrees.</font><br>
<font size="2" face="sans-serif"> Constant rounding mode table: Asking for a similar table for decimal, new clarifications</font><br>
<font size="2" face="sans-serif"> Rajan: FLT_RADIX 10: Need to make sure we agree on making it clear which one takes precedence or make it implementation defined.</font><br>
<font size="2" face="sans-serif"> Ex. Can be last one wins or it can be baised towards the respective type. i.e. If both present, DEC -> Decimal if present, non-DEC does standard if present</font><br>
<font size="2" face="sans-serif"> Jim: An implementation may want to keep them separate even if the radix is 10. For implementation reasons they may make them the same.</font><br>
<font size="2" face="sans-serif"> Marius: For implementation I would think making them the same would be worse.</font><br>
<font size="2" face="sans-serif"> Jim: If standard control affects decimal types they would want the opposite to be true too. Decimal control affects standard types.</font><br>
<font size="2" face="sans-serif"> *AI* Jim to draft changes regarding the discussion above and we will review.</font><br>
<font size="2" face="sans-serif"> *AI* A document will have to be delivered before the December meeting so please watch emails and respond quickly.</font><br>
<font size="2" face="sans-serif"> </font><br>
<font size="2" face="sans-serif"><b> Part 3:</b></font><br>
<font size="2" face="sans-serif"> Fred: Order of functions based by subclause number in C11 and subgroups are alphabetical. If we add new functions that will change subclause numbers.</font><br>
<font size="2" face="sans-serif"> Jim: We add letters to subclauses to avoid changing the numbers for later subclauses. Ex. 6.7.1.2#11 we add in 6.7.1.2#11a.</font><br>
<font size="2" face="sans-serif"> Mike: We could add a note describing why we are adding the a/b/c numbering.</font><br>
<font size="2" face="sans-serif"> *AI* Jim to add the note for parts 2 on (since 1 is in ballot). Also check to see if this can be added in Part 1 as well.</font><br>
<font size="2" face="sans-serif"> Fred: Why doesn't part 3 have the IEC_60559_TYPES with _EXT?</font><br>
<font size="2" face="sans-serif"> Jim: Part 1 shows the required things based on Annex F. The WANT macro is just an addition of identifiers for an extension. The programmer asks for these explicitly. The implementaiton must support these.</font><br>
<font size="2" face="sans-serif"> The goal is to have a WG14 review after the Spring 2014 meeting.</font><br>
<font size="2" face="sans-serif"> Mike: It is good to have Part 2 well underway before working on Part 3.</font><br>
<font size="2" face="sans-serif"> Jim: Part 2 should be available for ISO ballot next month.</font><br>
<font size="2" face="sans-serif"> Jim: One of the most complicated parts due to the type system changes and changes to part 1 and 2.</font><br>
<font size="2" face="sans-serif"> Mike: Some guidance on where to focus the review would be helpful.</font><br>
<font size="2" face="sans-serif"> Fred: ceil and ceiling issue: In C99 they use the mathematical symbol (L, backwards L etc.) vs the words.</font><br>
<font size="2" face="sans-serif"> *AI* Jim to try to use the math symbols for ceiling and floor instead of the words ceiling and floor.</font><br>
<font size="2" face="sans-serif"> Wording issue on page 20: Jim has talked to the C11 editor and is still looking into it.</font><br>
<font size="2" face="sans-serif"> </font><br>
<font size="2" face="sans-serif"><b> Part 4:</b></font><br>
<font size="2" face="sans-serif"> Mike: Long lists of functions can cause oversights and missed functions. Perhaps group them using root names instead of listing them all.</font><br>
<font size="2" face="sans-serif"> Jim: Following part 2 and part 3, so this change would affect those as well.</font><br>
<font size="2" face="sans-serif"> *AI* Jim to look for opportunities for shortening function lists by removing suffixes.</font><br>
<font size="2" face="sans-serif"> Jim: This part was more straightforward as it was basically just adding functions so less interactions with other parts.</font><br>
<font size="2" face="sans-serif"> Will need help getting the special cases stated correctly.</font><br>
<font size="2" face="sans-serif"> *AI* Jim to send a note to the 754 group to get review from them.</font><br>
<font size="2" face="sans-serif"> </font><br>
<font size="2" face="sans-serif"> Overview:</font><br>
<font size="2" face="sans-serif"> Is duplicating the intro section in all parts good?</font><br>
<font size="2" face="sans-serif"> No sentiment to remove it.</font><br>
<font size="2" face="sans-serif"> *AI* Remove the bold N in 5.3 function lists.</font><br>
<br>
<font size="2" face="sans-serif"> Rajan: *AI* Issue: We don't require conformance to part 3, and don't say _FloatNx (for example) must follow Part 3 so the functions are defined but are not the same as intended if an implemenatation has _FloatNx types but not Part 3 based.</font><br>
<br>
<font size="2" face="sans-serif"> Pi functions:</font><br>
<font size="2" face="sans-serif"> Fred: pg 5 ln 17: NaN is not in the interval but it shouldn't be a domain error.</font><br>
<font size="2" face="sans-serif"> Jim: Took it from text for acos directly from the C11 standard.</font><br>
<font size="2" face="sans-serif"> Fred: Not sure what the half-revolutions means. First and second instance.</font><br>
<font size="2" face="sans-serif"> Jim: Took it from the description of the trig functions.</font><br>
<font size="2" face="sans-serif"> David: The second one is redundant.</font><br>
<font size="2" face="sans-serif"> *AI* Jim to drop the second "half-revolutions"</font><br>
<font size="2" face="sans-serif"> </font><br>
<font size="2" face="sans-serif"> atan2pi:</font><br>
<font size="2" face="sans-serif"> Fred: Can't figure out what the functions do from the description.</font><br>
<font size="2" face="sans-serif"> Jim: Using the 754 descriptions.</font><br>
<font size="2" face="sans-serif"> David: Can say it is y/x divided by Pi in the right hand plane mathematically.</font><br>
<font size="2" face="sans-serif"> Jim: Can refer to the mathematical arctan function.</font><br>
<font size="2" face="sans-serif"> Jim: There is no corresponding statement for that for atan2.</font><br>
<font size="2" face="sans-serif"> *AI* Jim to flag the description wording as an issue.</font><br>
<font size="2" face="sans-serif"> </font><br>
<font size="2" face="sans-serif"> Fred: C11 says a domain error can occur if both arguments are zero.</font><br>
<font size="2" face="sans-serif"> *AI* Jim to add in atan2pi has a domain error for both arguments being zero.</font><br>
<br>
<font size="2" face="sans-serif"> exp2m1:</font><br>
<font size="2" face="sans-serif"> Fred: exp2m1(a large negative number) is not a range error.</font><br>
<font size="2" face="sans-serif"> Jim: Same as above. The words are from the C11 function.</font><br>
<font size="2" face="sans-serif"> </font><br>
<font size="2" face="sans-serif"> log21p:</font><br>
<font size="2" face="sans-serif"> Jim: 754 has log2p1. We already have log1p with the same description.</font><br>
<font size="2" face="sans-serif"> *AI* Issue here since it could be read as log 21 p instead of log2 1p.</font><br>
<font size="2" face="sans-serif"> </font><br>
<font size="2" face="sans-serif"> rsqrt:</font><br>
<font size="2" face="sans-serif"> *AI* Need to add a domain error.</font><br>
<br>
<font size="2" face="sans-serif"> compoundn:</font><br>
<font size="2" face="sans-serif"> Fred: Why are we using long int?</font><br>
<font size="2" face="sans-serif"> Jim: This was from the earlier discussion we had.</font><br>
<font size="2" face="sans-serif"> Ian: More instructions are needed for PPC hence long int is more efficient.</font><br>
<font size="2" face="sans-serif"> *AI* Jim to mark this as an issue as to why is it not an long long int.</font><br>
<font size="2" face="sans-serif"> </font><br>
<font size="2" face="sans-serif"> Annex F changes:</font><br>
<font size="2" face="sans-serif"> Please review carefully.</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></body></html>