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

[Jan Hubicka <hubicka at ucw dot cz>]

> One alternative I can think of is to make gcc build a database of the 
> annotations it computed while compiling libstdc++, and letting it use that 
> information when compiling applications that use libstdc++. For a single 
> library that is always used this seems ugly and doable, but it does not 
> scale so well.

This scheme, while it can be implemented, leads to problems with ABI
compatibility.  One of motivations for shared libraries is to make it
possible to replace them without having to recompile whole system and
being able to use them by different version of toolchains and different
compilers.  For the moment, ABI of shared library is given by what is
written in the header and linker scripts that is user controlled.  (this
is also why I don't think marking that rb tree manipulator static is ABI
breaking).  

As soon as compiler will derive some undefined amount of knowledge by
analyzing shared library source code and store it on-side into some
compiler specific database and use it for optimization of applications,
we will end up with completely undefined set of rules on what is part of
ABI. 

Honza
> 
> LTO could also help (I don't know how it works in gcc), delaying the real 
> compilation to a time where a libstdc++ augmented with all its inferred 
> annotations is available.
> 
> -- 
> Marc Glisse