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

Aaron Ballman via cfe-dev cfe-dev at lists.llvm.org
Tue Apr 4 12:21:20 PDT 2017


On Tue, Apr 4, 2017 at 2:39 PM, Hubert Tong
<hubert.reinterpretcast at gmail.com> wrote:
> On Tue, Apr 4, 2017 at 8:19 AM, Aaron Ballman <aaron at aaronballman.com>
> wrote:
>>
>> On Wed, Mar 22, 2017 at 8:45 PM, Hubert Tong via cfe-dev
>> <cfe-dev at lists.llvm.org> wrote:
>> > On Wed, Mar 22, 2017 at 7:21 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>> >>
>> >>
>> >> 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?
>> >
>> > That depends on what you mean by "unwind". Exceptions will go past all
>> > such
>> > code without executing destructors.
>>
>> Will throwing always result in calling std::terminate()? If so, does
>> that call happen immediately upon executing the throw statement?
>>
>> Or, if you have one TU compiled with -fignore-exceptions that throws,
>> and a second TU with -fno-ignore-exceptions that catches the exception
>> thrown from the first TU, can the exception still be caught?
>
> The exception can still be caught.

Thank you -- I think this is useful functionality. I'm a little bit
worried about the proliferation of exception-disabling-related flags,
but that's more an issue with how this gets surfaced rather than the
functionality itself.

~Aaron

>
>>
>>
>> ~Aaron
>>
>> >
>> >>
>> >>
>> >>  -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
>> >
>> >
>> >
>> > _______________________________________________
>> > cfe-dev mailing list
>> > cfe-dev at lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> >
>
>



More information about the cfe-dev mailing list