Quantcast

RFC: allowing EH constructs, but not generating handlers/cleanups

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RFC: allowing EH constructs, but not generating handlers/cleanups

Brian Cain via cfe-dev
-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.

-- HT


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC: allowing EH constructs, but not generating handlers/cleanups

Brian Cain via cfe-dev


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
[hidden email]
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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC: allowing EH constructs, but not generating handlers/cleanups

Brian Cain via cfe-dev
On Wed, Mar 22, 2017 at 7:21 PM, Hal Finkel <[hidden email]> 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.
 

 -Hal


-- HT



_______________________________________________
cfe-dev mailing list
[hidden email]
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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC: allowing EH constructs, but not generating handlers/cleanups

Brian Cain via cfe-dev
On Wed, Mar 22, 2017 at 8:45 PM, Hubert Tong via cfe-dev
<[hidden email]> wrote:

> On Wed, Mar 22, 2017 at 7:21 PM, Hal Finkel <[hidden email]> 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?

~Aaron

>
>>
>>
>>  -Hal
>>
>>
>> -- HT
>>
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> 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
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC: allowing EH constructs, but not generating handlers/cleanups

Brian Cain via cfe-dev
On Tue, Apr 4, 2017 at 8:19 AM, Aaron Ballman <[hidden email]> wrote:
On Wed, Mar 22, 2017 at 8:45 PM, Hubert Tong via cfe-dev
<[hidden email]> wrote:
> On Wed, Mar 22, 2017 at 7:21 PM, Hal Finkel <[hidden email]> 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.
 

~Aaron

>
>>
>>
>>  -Hal
>>
>>
>> -- HT
>>
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> 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
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC: allowing EH constructs, but not generating handlers/cleanups

Brian Cain via cfe-dev
On Tue, Apr 4, 2017 at 2:39 PM, Hubert Tong
<[hidden email]> wrote:

> On Tue, Apr 4, 2017 at 8:19 AM, Aaron Ballman <[hidden email]>
> wrote:
>>
>> On Wed, Mar 22, 2017 at 8:45 PM, Hubert Tong via cfe-dev
>> <[hidden email]> wrote:
>> > On Wed, Mar 22, 2017 at 7:21 PM, Hal Finkel <[hidden email]> 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
>> >> [hidden email]
>> >> 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
>> > [hidden email]
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> >
>
>
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Loading...