[Cfp-interest] draft of syntax discussion for C committee

[Jim Thomas]

Our job in Part 5 is to specify (and get approved) the best C binding we can for what 754-2008 recommends for (among other things) alternate exception handling. The current C facilities for managing exception flags don’t provide all that 754-2008 recommends.

With the current C model one can write code to deal with exceptions, like

{
	#pragams STDC FENV_ACCESS ON
	fenv_t env;
	feholdexcept(&env, FE_INVALID);
	… main case code …
	if (fetestexcept(FE_INVALID) {
		… handle invalid case …
		feclearexcept(FE_INVALID);
	}
	feupdateenv(&env);
}

Subexceptons could be added in the obvious way.

Other limitation of this approach are not so easily addressed (as noted by David and others in previous email):

With this approach, the user has to work with flags (and the tedious details of the feholdexcept and feupdateenv functions), instead of exceptions which are arguably the more natural concept and what 754-2008 alternate exception handling refers to. 

This approach doesn’t support ASAP exception handling. All of the main case code executes, even if an exception occurs early. This might be addressed by sprinkling fetestexcept calls through the main case code, but that would slow done the presumably ordinary case when an invalid exception does not occur, and would further clutter the code. Effective placement of the flag tests would require implementation-specific knowledge about the efficiency of accessing flags.

This approach cannot be used to detect exact underflow exceptions (which do not raise flags).

The implementation can not take advantage of HW traps or special instructions that might allow more efficient handling of exceptions.

An approach with more try-catch like semantics (as we’ve been discussing the past few weeks) can provide a binding for more of what 754-2008 recommendations. I don’t think we’ve converged on a syntax. David has mostly completed a note we can send to WG14 to ask for input on what syntax might be acceptable. For our teleconference this Thursday, I suggest we try to resolve any issues that are blocking getting this note completed.

-Jim


On Jun 9, 2014, at 6:14 AM, Rajan Bhakta <rbhakta at us.ibm.com> wrote:

> Not to derail the discussion, but Fred's point about interaction with the existing C support for signal handlers leads to the thoughts of the existing C support for (floating point) exceptions in 7.6.2. 
> 
> I can't recall (nor can I find in my notes) any discussion about extending what is already in the C standard for floating point exceptions. 
> 
> Although arguably not as convenient as what we are discussing right now, can we not add in new macros as we are already discussing for the floating point exceptions, and use the existing feclearexcept, fegetexceptflag, feraiseexcept, fesetexceptflag, and fetestexcept functions? 
> 
> The example code given in the standard shows how to do pretty much everything we are discussing, though more verbosely. 
> 
> The advantages are that it is building on something that is already in the C standard and hence more easily accepted by both the C committee, implementers and users due to its familiarity, and avoids "ugly" pragmas. Also, the signal handling issue falls under the current C standard model so we do not need to specify anything extra here (whereas we would for the try-catch/pragma style model). 
> 
> The disadvantages are that it is not as "clean" as the C++ style exception handling, it may make it harder for optimizing compilers to recognize the exception pattern (though I would argue it is actually easier on the compiler and hardware with the current C standard way), and in a non-optimizing case, may be much slower on some hardware. 
> 
> Now there may be the issue of lack of bits (given exceptions are stored in int's from the interface) on some implementations, but that can be worked around (ex. version check, or even a new set of functions created for these new sub-exceptions). 
> 
> 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 
> 
> 
> 
> From:        "Fred J. Tydeman" <tydeman at tybor.com> 
> To:        "cfp-interest at ucbtest.org" <cfp-interest at ucbtest.org>, 
> Date:        06/06/2014 10:37 PM 
> Subject:        Re: [Cfp-interest] draft of syntax discussion for C committee 
> Sent by:        cfp-interest-bounces at oakapple.net 
> 
> 
> 
> On Fri, 6 Jun 2014 16:25:15 -0700 (PDT) David Hough CFP wrote:
> >
> > #pragma STDC catch_fe fe_exception1 label1
> > #pragma STDC catch_fe fe_exception2 label2
> 
> What is the interaction between this idea and
> a signal handler for SIGFPE?
> 
> 
> ---
> Fred J. Tydeman        Tydeman Consulting
> tydeman at tybor.com      Testing, numerics, programming
> +1 (775) 287-5904      Vice-chair of PL22.11 (ANSI "C")
> Sample C99+FPCE tests: http://www.tybor.com
> Savers sleep well, investors eat well, spenders work forever.
> 
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest
> 
> 
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20140610/a45198f6/attachment-0001.html