This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: throw(), pure and const flags on functions
>
> I'm not suggesting that the compiler should accomplish miracles
> for things it knows nothing about. However, I'm also unimpressed
> that one has to annotate both versions of _tree_increment
> (for example),
Well, both implementations of _tree_increments lie in .cc file. You
can tell they are obviously the same after looking into it. So GCC can.
You can't tell it from the standard header and neither GCC can.
The header is all information compiler is given at a time compiling
application using RB trees.
Those functions are part of iterators of very basic datastructure that
are supposed to be useable in application's internal loop and give good
performance. Those few missing markers makes GCC's analysis of throw
and const/pure flags to degrade on any application using those. Any
kind of optimization that tries to propagate across callgraph needs good
information to start with, otherwise it won't do anything useful.
It is kind of implementation quality bug that the other one liner is
hidden in .cc file when in the template itself it would cause no harm
and make it easier for GCC to work out what is going on, but since it is
part of API now, we can't change that easilly.
Honza
- References:
- Re: throw(), pure and const flags on functions
- Re: throw(), pure and const flags on functions
- Re: throw(), pure and const flags on functions
- Re: throw(), pure and const flags on functions
- Re: throw(), pure and const flags on functions
- Re: throw(), pure and const flags on functions
- Re: throw(), pure and const flags on functions
- Re: throw(), pure and const flags on functions
- Re: throw(), pure and const flags on functions
- Re: throw(), pure and const flags on functions