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: Mark va_start as nothrow


On Fri, Apr 17, 2009 at 9:00 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> Richard Guenther wrote:
>
>> That would work for the C++ runtime (built with -fexceptions), but for
>> example glibc annotates functions with throw() as well, without
>> catching uncaught exceptions (I'm not even sure there is an equivalent
>> for C, even if we would build with -fexceptions?).
>
> I think it's reasonable to say that if you call a function in a library
> that wasn't built with -fnon-call-exceptions that you can't expect it to
> throw such exceptions.
>
> But, to return to the core issue, I think that GCC's internal model of
> builtin functions, when compiling with -fnon-call-exceptions, ought to
> be that any external functions might raise such exceptions. ?GCC doesn't
> know how that function is implemented in the library; maybe it throws
> exceptions, maybe it doesn't. ?It seems to me that assuming "throw()"
> specifications on all builtins is aggressive; in the presence of
> -fnon-call-exceptions, we should assume that maybe the builtin does
> throw an exception. ?Unless we really know that it can't, because, for
> example, it's a builtin that just multiplies two integers, or something.
>
> The empty exception specification for builtins is an optimization, but
> with -fnon-call-exceptions, it doesn't sound like a safe optimization.

I agree.  I guess the C++ standard doesn't specify what throw() means
for non-call-exceptions?

Of course this is all a pre-existing problem and worth a bugzilla.

Richard.


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