Re: throw(), pure and const flags on functions

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

On Wed, Apr 15, 2009 at 11:10 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> 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.

Yet, that was part of the patch that was offered so that we
can look at the issue in greater detail.

>
> 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.

Well, I think it would be a mistake to talk of the library code as an
abstract entity  nobody cares about how it was written.

Concerning the the build at -O0, how many peopl care about the
code size AND don't actually use -Os?

>
> 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,

Me too.

> without optimization there are certainly going to be cases that the
> compiler won't figure out that it otherwise could.

Of course!

However, the argument of people worrying about code size of
tiny embedded systems but not using -Os looks a bit curious
to me.

>?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.

Yes, the facility should not just be for libstdc++ maintainers
to that they should add more uglification.

>?But, the libstdc++ maintainers should be
> willing to add annotations if necessary to make user programs smaller

I suspect the discussion has been about the meaning of 'if necessary',
not about an 'unwillingness'.

> 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

If I were arguing absolutely against annotations, I think would have
been less waffling than you appear to imply :-)

> 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.

Well, that I am a bit less enthusiastic about.

'throw()' has viral effect far more devastating than appear.
If we start warning about absence of 'throw()', the net effect
is that people would start putting those stuff almost everywhere.
and I think the cure might be worse than the desease.


-- Gaby