[cfe-dev] RFC: allowing EH constructs, but not generating handlers/cleanups

Hal Finkel via cfe-dev cfe-dev at lists.llvm.org
Wed Mar 22 16:21:47 PDT 2017


On 03/22/2017 06:17 PM, Hubert Tong via cfe-dev wrote:
> -fno-exceptions causes EH constructs such as try/catch, 
> function-try-blocks, and throw expressions to be diagnosed with a 
> severe error. That is, -f[no-]exceptions controls a language-support 
> property.
>
> For experiments in evaluating the cost of (unused) exception handling, 
> and for cases where components are being deployed with the expectation 
> that exceptions will not be thrown, etc. it is useful to allow EH 
> constructs in the source, but to generate code with no handlers or 
> cleanups.
>
> I think that it still makes sense under such a mode to allow throw 
> expressions to throw. This is consistent with -fno-exceptions still 
> calling __cxa_bad_cast and __cxa_bad_typeid (which GCC also does, but 
> not with __cxa_throw_bad_array_new_length).
>
> That is, the proposed semantics is essentially the same as for 
> -fno-exceptions, except to treat try/catch and function-try-blocks as 
> just normal code introducing no handlers, and to allow throw expressions.
>
> -fno-exceptions already suppresses creation of cleanups for unwinding 
> and the ignoring of exception specifications.
>
> I like to think of this as -fignore-exceptions. I have a use for this, 
> and I would like to know what people think.

To summarize, code compiled with -fignore-exceptions can throw, but 
can't catch anything. All exceptions just unwind through all such code. 
Is that right?

  -Hal

>
> -- HT
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170322/fce56d55/attachment.html>


More information about the cfe-dev mailing list