throw(), pure and const flags on functions

[Mark Mitchell]

Gabriel Dos Reis wrote:

>>> Many of the C functions we call are standard C functions.

>> But some probably are not.  So, annotations are still useful in some cases.

> really does not know.  That is not clear.  For example that
> both versions of _tree_increment should be annotated when
> one is clearly a forward to the other is a bit suspicious of the
> efficacy of the analysis.

That's clearly not an issue about underlying C library functions, though.

People care about the code generated at -O0, i.e., without inlining.  In
particular, code size can matter -- if your program doesn't fit on your
embedded target when unoptimized, that can be a problem.  Removing
unused implicitly-generated exception regions does not affect
debuggability; by construction, there's no way for a user to talk about
them, set a breakpoint there, etc.

I don't know if the analysis Jan is doing works at -O0, or not.  If it
doesn't, I'd like to know if it can, at least to some extent.  But,
without optimization there are certainly going to be cases that the
compiler won't figure out that it otherwise could.  Therefore, it may
still be valuable to mark functions in the library as not throwing
exceptions.

Users don't care about how hard it was to write the library.  They care
only about how well it works.  Of course we should make the compiler as
smart as we can; that saves work for users, including, but not limited
to, the libstdc++ maintainers.  But, the libstdc++ maintainers should be
willing to add annotations if necessary to make user programs smaller
and/or faster, even if that is somewhat untidy, and even if the compiler
could sometimes do better.

I can't tell if you're arguing against adding annotations or not.  I
think we should add them to declarations of functions that cannot throw
exceptions, if those functions call only other functions that do not
throw exceptions, and if that improves the code generated at any level
of optimization.  I think we should have compiler warnings to help with
this: both a warning that a function could safely be declared as
"throw()", and a warning that a function declared "throw()" calls
functions that themselves appear capable of throwing exceptions.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713