<font size=2 face="sans-serif">2015/04/07, 12:00 EST:</font>
<br><font size=2 face="sans-serif"><b> Attendees</b>: Rajan, Jim,
Fred, Mike, Marius, Ian, David</font>
<br>
<br><font size=2 face="sans-serif"><b> New agenda items:</b></font>
<br><font size=2 face="sans-serif"> None.</font>
<br>
<br><font size=2 face="sans-serif"><b> Last meeting action items:</b></font>
<br><font size=2 face="sans-serif"> Jim: cfp5-diff-20150211-20150309.pdf:
p4: Line 28: Check if 'indeterminate' is the right term. - Done.</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-diff-20150211-20150309.pdf:
p8: State what the default state is for #pragma STDC FENV_REPRODUCIBLE
and what happens when it is OFF. - Done.</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-diff-20150211-20150309.pdf:
p9: Line 5: program code -> something else such as 'code sequence' or
'code segment' or 'Following are requirements for code in the whole program
or part of a program'. - Done.</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-diff-20150211-20150309.pdf:
p9: Line 10: Note that we need to make sure functions with two or more
arguments (since the order of evaluation of them is not fixed) is handled.
- Still open.</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-diff-20150211-20150309.pdf:
p9: Line 32: The other fused multiply functions need to be listed here.
- Done.</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-diff-20150211-20150309.pdf:
p9: Line 36: Remove "propagation, " - Done.</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-diff-20150211-20150309.pdf:
p9: Line 37: Look into tightening the underflow and inexact part. - Still
open.</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-diff-20150211-20150309.pdf:
p10: Line 12: Change the statement to make sure that style 'a' applies
to the entire statement. - Done.</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-20150317.pdf:
p10: Line 8: unspecified -> indeterminate - Done.</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-20150317.pdf:
p10: Line 16: unspecified -> indeterminate - Done.</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-20150317.pdf:
p10: Line 16: Remove duplicated text. - Done.</font>
<br><font size=2 face="sans-serif"> Jim: Part 5: Reproduciblity:
Add in don't use alternate exception handling. - Not done. Not sure if
this should be a restriction. Bring up for discussion.</font>
<br><font size=2 face="sans-serif"> Jim: Make the updates
to part 5 and poll the group to see what to do for the C meeting. - Done
(n1919 posted for the C meeting - Does not have alternate exception handling).</font>
<br>
<br><font size=2 face="sans-serif"><b> New action items:</b></font>
<br><font size=2 face="sans-serif"> Jim: cfp5-diff-20150211-20150309.pdf:
p9: Line 10: Note that we need to make sure functions with two or more
arguments (since the order of evaluation of them is not fixed) is handled.</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-diff-20150211-20150309.pdf:
p9: Line 37: Look into tightening the underflow and inexact part.</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-20150330.pdf:
p4: Line 20: FLT_EVAL_METHOD -> DEC_EVAL_METHOD</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-20150330.pdf:
p4: Line 32: actually -> actual</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-20150330.pdf:
p6: Line 23: Take into account rounding direction.</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-20150330.pdf:
p7: line 25 is misnumbered. It appears that one of the blank lines
between 20 and 25 has a number.</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-20150330.pdf:
p7: Line 10 is a line number on a blank line</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-20150330.pdf:
p7: Last line: "NOTEIEC" appears to be missing a space. It has
a tab.</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-20150330.pdf:
p7: Lines 31-32: Consider adding note about directed rounding</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-20150330.pdf:
p9: Lines 3 and 6: Consider clearer wording, maybe identifying IEEE/IEC
section number</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-20150330.pdf:
p10: Line 43: NOEXCEPT: Like default, but no flag is set: wording improvement
needed.</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-20150330.pdf:
p11: Line 3: OPTEXCEPT: Like default, but flag setting is optional: wording
improvement needed.</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-20150330.pdf:
p11: Line 4: Reference IEEE for the meaning of 'tiny'. Also look into 'preliminary'
and exact underflow.</font>
<br><font size=2 face="sans-serif"> Jim: cfp5-20150330.pdf:
p11: Line 21: affect -> effect </font>
<br><font size=2 face="sans-serif"> Jim: cfp5-20150330.pdf:
p11: Line 29: Remove "undefined behaviour" statement for every
action that has a "shall" requirement already (BREAK, GOTO, DELAYED_GOTO).</font>
<br>
<br><font size=2 face="sans-serif"><b> Next Meeting:</b></font>
<br><font size=2 face="sans-serif"> May 19th, 2015, 12:00
EST, 9:00 PDT</font>
<br><font size=2 face="sans-serif"> Same teleconference number.</font>
<br>
<br><font size=2 face="sans-serif"><b> Discussion:</b></font>
<br><font size=2 face="sans-serif"> WG14 meeting:</font>
<br><font size=2 face="sans-serif"> Rajan and Fred
attending.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> What should we
do for alternate exception handling for the WG14 meeting?</font>
<br><font size=2 face="sans-serif"> We can post
what we have, but not require comment or analysis from WG14.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Jim has been awarded
the INCITS award for excellence for the work on these TS's. This should
be brought up in WG14 to show the value of this work.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Part 1: Published.</font>
<br>
<br><font size=2 face="sans-serif"> Part 2: Published.</font>
<br><font size=2 face="sans-serif"> The flawed version
was published due to changes from ISO before we had a chance to review
their changes.</font>
<br><font size=2 face="sans-serif"> Jim is working
with the Word draft that ISO used to get it fixed for something that can
be published.</font>
<br><font size=2 face="sans-serif"> Issues with
fonts, page breaks, line breaks, bullets, etc. all changing.</font>
<br><font size=2 face="sans-serif"> A similar
thing happened with IEEE's spec.</font>
<br>
<br><font size=2 face="sans-serif"> Part 3: Ballot closed.
Passed without comments.</font>
<br><font size=2 face="sans-serif"> Recommend publishing
after editorial changes. See issues with Part 2.</font>
<br>
<br><font size=2 face="sans-serif"> Part 4: Ballot closed.
Passed without comments.</font>
<br><font size=2 face="sans-serif"> Recommend publishing
after editorial changes. See issues with Part 2.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Part 5:</font>
<br><font size=2 face="sans-serif"> Note: There will
be duplicated notes at the end due to two separate note takers notes being
merged. Both have been left to avoid missing anything.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> cfp5-20150330.pdf:</font>
<br><font size=2 face="sans-serif"> *ToDo: Jim:
cfp5-20150330.pdf: p4: Line 20: FLT_EVAL_METHOD -> DEC_EVAL_METHOD</font>
<br><font size=2 face="sans-serif"> *ToDo: Jim:
cfp5-20150330.pdf: p4: Line 32: actually -> actual</font>
<br><font size=2 face="sans-serif"> p6: Should
we change what is listed to put in the words to say "includes the
following" or leave it as is?</font>
<br><font size=2 face="sans-serif"> Leave
it as is.</font>
<br><font size=2 face="sans-serif"> p6: Line
22: Not true due to rounding directions. Needs to be changed. Can get rounding
in the opposite direction.</font>
<br><font size=2 face="sans-serif"> Directed
rounding users probably don't want any optimization so they would not allow
this optimization.</font>
<br><font size=2 face="sans-serif"> These
optimizations are valid for real variables. Only invalid for floating point
due to limits.</font>
<br><font size=2 face="sans-serif"> The
rational is that they are equivalent in real arithmetic and not in IEEE
representations.</font>
<br><font size=2 face="sans-serif"> This
could mean we allow other properties of real numbers as well. Do we want
that slippery slope?</font>
<br><font size=2 face="sans-serif"> Associative
and Distributive seem to be different properies. The recipricol multiply
is done by our compiler (ex. if it is a compile time constant and a power
of 2, it is always done). This is different from line 7 but similar.</font>
<br><font size=2 face="sans-serif"> It
is the same with the associative law.</font>
<br><font size=2 face="sans-serif"> Prefer
two separate pragma's but fine with this the way it is.</font>
<br><font size=2 face="sans-serif"> Will
impact existing compilers to determine what overrides what.</font>
<br><font size=2 face="sans-serif"> *ToDo: Jim:
cfp5-20150330.pdf: p6: Line 23: Take into account rounding direction.</font>
<br><font size=2 face="sans-serif"> ---</font>
<br><font size=2 face="sans-serif"> Page 6 lines
23-25 distributed law over subtraction:</font>
<br><font size=2 face="sans-serif"> Jim:
You can do this in non-directed rounding modes.</font>
<br><font size=2 face="sans-serif"> David:
Not true in any rounding mode, but this pragma permits it.</font>
<br><font size=2 face="sans-serif">
Minuses introduce other issues.</font>
<br><font size=2 face="sans-serif">
This pragma allows doing it.</font>
<br><font size=2 face="sans-serif">
Assume anyone using it either doesn't use directed
rounding or doesn't mind the change.</font>
<br><font size=2 face="sans-serif">
Lines 5-7 are similar.</font>
<br><font size=2 face="sans-serif"> Page 7 line
25 is misnumbered. It appears that one of the blank lines between
20 and 25 has a number. Jim to fix.</font>
<br><font size=2 face="sans-serif"> Page 7 line
10 is a line number on a blank line. Jim to fix.</font>
<br><font size=2 face="sans-serif"> Page 7 last
line "NOTEIEC" appears to be missing a space. It has a tab. Jim
to fix???</font>
<br><font size=2 face="sans-serif"> Jim: Change
bars sometimes appear to apply to a line above or below the changes.</font>
<br><font size=2 face="sans-serif"> Page 7 lines
31-32:</font>
<br><font size=2 face="sans-serif"> Jim:
The last one "x-y*z" may not be valid with directed rounding.</font>
<br><font size=2 face="sans-serif"> David:
OK? One who cares can use fma function.</font>
<br><font size=2 face="sans-serif"> Fred:
x-y*z should be z-x*y.</font>
<br><font size=2 face="sans-serif"> Jim:
Not saying these expressions are equivalent, so OK as is.</font>
<br><font size=2 face="sans-serif"> Jim
to consider adding note about directed rounding.</font>
<br><font size=2 face="sans-serif"> David:
Maybe list all expressions on line 26?</font>
<br><font size=2 face="sans-serif"> Page 8 Joseph
asked about assignments and function call results, so Jim expanded example.</font>
<br><font size=2 face="sans-serif"> Ian:
Also function parameters [needing conversion]? Jim: Yes.</font>
<br><font size=2 face="sans-serif"> Also
includes clarification Fred requested.</font>
<br><font size=2 face="sans-serif"> Page 9 line
3: Only equivalent if implementation supports pragma.</font>
<br><font size=2 face="sans-serif"> (Skip section
9 Alternate exception handling for now.)</font>
<br><font size=2 face="sans-serif"> Page 13
lines 29-33:</font>
<br><font size=2 face="sans-serif"> Jim
disagrees that reproducibility excludes all alternate exception handling,
so rewrote this to be more specific.</font>
<br><font size=2 face="sans-serif"> Page 14
lines 14-15 character sequence conversions:</font>
<br><font size=2 face="sans-serif"> The
conversion functions are IEEE/IEC operations, so need mentioning.</font>
<br><font size=2 face="sans-serif"> Page 9 section
9 Alternate exception handling:</font>
<br><font size=2 face="sans-serif"> Jim
added text for context.</font>
<br><font size=2 face="sans-serif"> Wrote
draft of pragmas equivalent to try/catch suggestion.</font>
<br><font size=2 face="sans-serif"> Is
action the right word? Ian and David: Yes.</font>
<br><font size=2 face="sans-serif"> Page 9 lines
3 and 6:</font>
<br><font size=2 face="sans-serif"> David:
Why mention "to narrower type"?</font>
<br><font size=2 face="sans-serif"> Jim:
Add rounding to narrower type identifies which IEEE/IEC functions this
applies to.</font>
<br><font size=2 face="sans-serif">
Jim to consider clearer wording, maybe identifying IEEE/IEC
section number.</font>
<br><font size=2 face="sans-serif">
Other places have similar wording.</font>
<br><font size=2 face="sans-serif"> Page 10
lines 39... Action:</font>
<br><font size=2 face="sans-serif"> Page 10
lines 42-43:</font>
<br><font size=2 face="sans-serif"> David:
NOEXCEPT is like default except flag must not be set (could be expensive).</font>
<br><font size=2 face="sans-serif"> Jim
to improve wording.</font>
<br><font size=2 face="sans-serif"> Page 11
lines 1-3: Jim to improve wording.</font>
<br><font size=2 face="sans-serif"> Page 11
line 4 abrupt underflow: "tiny" means the same as in IEEE/IEC.
Jim to reword or refer to IEEE definition.</font>
<br><font size=2 face="sans-serif"> Page 11
line 5: Fred: IEEE does not use "preliminary". Jim: Two roundings.
Jim to improve wording.</font>
<br><font size=2 face="sans-serif"> David:
IEEE defines numeric result, so don't need to do that here.</font>
<br><font size=2 face="sans-serif"> Jim
to improve (simplify?) wording.</font>
<br><font size=2 face="sans-serif"> Page 11
line 21: "affect" => "effect".</font>
<br><font size=2 face="sans-serif"> Page 11
lines 28-29: Fred: Compiler can detect error, not make this undefined.</font>
<br><font size=2 face="sans-serif"> Rajan:
Needs rewording that action shall not be used outside a compound statement.</font>
<br><font size=2 face="sans-serif"> Jim:
Do any std macros have constraints?</font>
<br><font size=2 face="sans-serif"> Rajan:
Upcoming defect may resolve this.</font>
<br><font size=2 face="sans-serif"> Rajan:
Don't need last sentence. Jim to remove it.</font>
<br><font size=2 face="sans-serif"> Page 11
lines 32-33: Jim to remove "Use of the pragma with this action outside
any compound statement results in undefined behavior."</font>
<br><font size=2 face="sans-serif"> Page 11
lines 40-41: Ditto.</font>
<br><font size=2 face="sans-serif"> Page 11
lines 43-47: Jim: Implementation?</font>
<br><font size=2 face="sans-serif"> David:
Just generate code and test flag at end?</font>
<br><font size=2 face="sans-serif">
What if the only exception is
an exact underflow which doesn't set a flag? Then it couldn't be detected.</font>
<br><font size=2 face="sans-serif"> Jim:
That small if is a big if.</font>
<br><font size=2 face="sans-serif"> Ian:
Does programmer really care about an exact underflow?</font>
<br><font size=2 face="sans-serif"> David:
Sometimes you don't want a subnormal.</font>
<br><font size=2 face="sans-serif"> Jim:
Issue between underflow, overlfow and exact when using default?</font>
<br><font size=2 face="sans-serif"> ---</font>
<br><font size=2 face="sans-serif"> p10: Line
39: NOEXCEPT: Like default, but no flag is set.</font>
<br><font size=2 face="sans-serif"> This
means that if hardware sets a flag, it would have to be unset.</font>
<br><font size=2 face="sans-serif"> *ToDo:
Jim: cfp5-20150330.pdf: p10: Line 43: NOEXCEPT: Like default, but no flag
is set: wording improvement needed.</font>
<br><font size=2 face="sans-serif"> p11:</font>
<br><font size=2 face="sans-serif"> *ToDo:
Jim: cfp5-20150330.pdf: p11: Line 3: OPTEXCEPT: Like default, but flag
setting is optional: wording improvement needed.</font>
<br><font size=2 face="sans-serif"> Abrupt:
What does 'tiny' mean? IEEE defines it. Should we reference IEEE here?</font>
<br><font size=2 face="sans-serif"> Floating
point standard doesn't use the word preliminary. Unrounded may be used.
But that gets into before or after rounding.</font>
<br><font size=2 face="sans-serif"> We
could remove the parenthetical and just refer to IEEE.</font>
<br><font size=2 face="sans-serif"> *ToDo:
Jim: cfp5-20150330.pdf: p11: Line 4: Reference IEEE for the meaning of
'tiny'. Also look into 'preliminary' and exact underflow.</font>
<br><font size=2 face="sans-serif"> *ToDo:
Jim: cfp5-20150330.pdf: p11: Line 21: affect -> effect
</font>
<br><font size=2 face="sans-serif"> Break:
Take out line 29 as the "shall" in the statement before already
requires a diagnostic or failure to translate.</font>
<br><font size=2 face="sans-serif"> *ToDo:
Jim: cfp5-20150330.pdf: p11: Line 29: Remove "undefined behaviour"
statement for every action that has a "shall" requirement already
(BREAK, GOTO, DELAYED_GOTO).</font>
<br><font size=2 face="sans-serif"> Delayed
Goto: Default exception handling may need work.</font>
<br><font size=2 face="sans-serif"> Only
applies to the exception list.</font>
<br><font size=2 face="sans-serif"> What
if the only exception is an exact underflow (so can't be detected by checking
the flag)?</font>
<br><font size=2 face="sans-serif"> What's
wrong with an exact underflow in the first place? People don't want the
subnormal?</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Looks like
we won't have anything for Part 9 that we want to bring forward to WG14
due to the large flux we're still going through working through the details.</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>