[Cfp-interest] WG14 IEEE 754-C binding meeting minutes 2014/07/12
Rajan Bhakta
rbhakta at us.ibm.com
Thu Jun 12 10:41:12 PDT 2014
2014/06/12, 12:00 EST:
Attendees: Rajan, Fred, Marius, David, Jim, Ian, Mike
New agenda items:
None.
Old action items:
David: Part 5: (From last meeting): Complete exception specification
with the full syntax dealing with scope and sub-exceptions. Include a
discussion document with reasons choices and alternatives. - Partially
done (more of an outline. Sent on 2014/05/12). Keep open.
David: Part 5: For fast_subnormal, change to "allows abrupt underflow"
-> "allows (but not requires) abrupt underflow". Done.
David: Part 5: Put in exception category in the sub-exceptions as the
prefix. Ex. FE_DIV_ZERO -> FE_DIVBYZERO_DIVIDES. Done.
David: Part 5: Add in FE_INVALID_OTHER and FE_DIVBYZERO_OTHER. Done.
David: Part 5: OPTFLAG -> MAY_FLAG, NOFLAG -> NO_FLAG, SUBSTITUTEXOR
-> SUBSTITUTE_XOR. Done first two, last is pending issue resolution.
Next meeting:
July 15th (Tuesday), 2014, 12:00 EST, 9:00 PDT
Same teleconference number.
New action items:
David: Syntax.txt: Add in the beginning something that gives the
purpose of the document. Ex. The CFP group is asking for feedback from
WG14 for ...
David: Syntax.txt: Semantics: Change exception1/exception2 to
exceptions1/exceptions2
David: Syntax.txt: Add to the end of the document other ideas
considered.
David: Syntax.txt: Add a sentence to handle thread and object state
considerations.
David: Syntax.txt: Add a sentence about ASAP vs deferred exception
handling (try-catch vs try-patch).
Discussion:
Part 1: Reviewing draft as edited by ISO. Jim has sent back comments
on changes made.
Part 2: DTS ballot issued.
Part 3: PDTS ballot issued.
Part 4: PDTS ballot issued.
Part 5: (Email discussion based) (http://www.validlab.com/cfp/*.txt)
http://www.validlab.com/cfp/syntax.txt
*ToDo: David: Add in the beginning something that gives the
purpose of the document. Ex. The CFP study group is asking for feedback
from WG14 for ...
*ToDo: David: Semantics: Change exception1/exception2 to
exceptions1/exceptions2
Should we add the other things we considered like:
1) PL/I, Basic and other languages "ON event DO/GOTO/GOSUB
handler"
2) Exception handler callback function registration (like signal
handlers)
3) Using SIGFPE signal handling
4) Testing flags with the existing C floating point environment
handling functions and adding in new flags like underflow
at the end of the document? Yes
*ToDo: David: Add to the end of the document other ideas
considered.
Mike: Avoiding extra nesting is advantageous if we don't do
try/catch.
Fred: How does what we do work with threads and object state?
Rajan: Should be written/stored to variables in the scope of the
exception handling be in an indeterminate state only?
Rajan: Also side effects are not known in sequencing.
Yes, we should cover both cases for object state.
For threads, this (exception handling) should be thread local
like the existing C Standard floating point environment being thread
local.
Fred: Signal handling in a multi-threaded program results in
undefined behaviour.
David will make the changes discussed and post it for review
before sending it out to the wider WG14 group.
Substitution (pre/xor):
David: Haven't looked at pre-substitution since it is cheaper to
do exception/test-and-branch.
Ex. Instead of "SUBSTITUTE(z = x / y, DIV_ZERO, z = x' / y')" do
"try { z = x / y; } catch (DIV_ZERO) { z = x' / y' }"
Easier to get one set of changes made rather than new syntax for
each part with their attendant issues and potential problems. This means
the exception handling approach is better.
Raise-no-flag:
David: Requires trapping, otherwise flags would be raised.
Shows that the programmer has explicitly thought about the flags.
i.e. opt-out vs opt-in
Can be done with a pragma or try/catch (if catch does not raise a
flag for the caught exception).
We can document how to use the exception handling (ex. try-catch) to
handle a lot of these items (substitution, may-flag, raise-no-flag, etc.).
Should we have two versions (asap-try-catch vs try-catch)? An ASAP
and a deferred one?
Perhaps have different catch's? catch vs deferred_catch/patch or a
#pragma that identifies the following code as ASAP or not.
Loops (indeterminate or large limits) may want to do asap while
smaller ones may want deferred. Should we give the compiler hints or
directives for this?
We should do both mechanisms since not doing asap means you can
use the flag checking instead.
catch can be implemented in patch, except for exact underflow
Regards,
Rajan Bhakta
z/OS XL C/C++ Compiler Technical Architect
ISO C Standards Representative for Canada
C Compiler Development
Contact: rbhakta at us.ibm.com, Rajan Bhakta/Houston/IBM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20140612/9aef6913/attachment.html
More information about the Cfp-interest
mailing list