This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]