This is the mail archive of the
mailing list for the GCC project.
Re: Mark va_start as nothrow
On Fri, Apr 17, 2009 at 9:00 PM, Mark Mitchell <email@example.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
Of course this is all a pre-existing problem and worth a bugzilla.