This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [3.3] Follow-up to C++ forced unwinding
- From: Roger Sayle <roger at www dot eyesopen dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 30 Apr 2003 20:32:26 -0600 (MDT)
- Subject: Re: [3.3] Follow-up to C++ forced unwinding
Firstly, please don't consider my comments below any reason not
to include RTH's patch in 3.3, which is better applied sooner
rather than later.
Richard, would it be reasonable to add support for a "cancellation"
attribute to GCC? My understanding is that we're trying to move
away from nothrow_libfn_p (because of lack of type checking and
-ffree-standing issues etc...) to using GCC built-ins. See thread
http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01937.html
A DECL_CAN_CANCEL predicate on function declarations would not only
allows us to record cancellation points in builtins.def, but would also
allow us to propagate cancellation information in the same way we do
purity, constancy, noreturn and nothrow.
Naturally, this is a 3.4+ timeframe issue. Certainly, by gcc 3.4
we'll be able to list all cancellable system functions in builtins.def
and return cfns.gperf to its current state. i.e. treat cancellation
the same way we handle "noreturn" on exit and abort and "malloc" on
malloc and alloca. Perhaps by 3.5, cfns.gperf will disappear entirely.
p.s. Whilst you're at it, a recent discussion concluded that "raise"
may indeed throw an exception, but I didn't submit a patch as I
didn't know how to regenerate the relevant gperf/cpref files.
http://gcc.gnu.org/ml/gcc/2002-09/msg00061.html
Roger
--
Roger Sayle, E-mail: roger@eyesopen.com
OpenEye Scientific Software, WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road, Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507. Fax: (+1) 505-473-0833