[LLVMdev] Fun with _GLIBCXX_DEBUG

[David A. Greene]

So far we've tracked down four bugs using _GLIBCXX_DEBUG, all of them quite 
subtle and some of them leading to serious problems like heap corruption.

But we've also discovered that compile time can skyrocket in some cases as the 
library does its checks. The standard library complexity guarantees don't 
apply with _GLIBCXX_DEBUG.

Therefore, we should figure out if we want to enable this in debug builds by 
default, include a configure option for it or create some new target 
(Developer?) that does a build that includes it.

Builds of llvm and llvm-gcc must be consistent in their use of _GLIBCXX_DEBUG.
That implies that any change to llvm in this respect must be reflected in 
llvm-gcc. Consequently, we're going to have a timing issue with any change to 
llvm to make sure both repositories get updated correctly and don't cause 
trouble for people.

In my local copy of llvm-gcc _GLIBCXX_DEBUG is turned on by --enable-checking.

So here are the questions we should wrestle with before making any changes:

- Do we want _GLIBCXX_DEBUG enabled in debug builds by default?

- Should it be a configure option?

- Should we create a new kind of build to include it?

- What's the strategy for llvm-gcc?

If we want to make this change, I can either submit patches to llvm-gcc or 
someone can give me commit access.  I don't care which it is, pick the one 
that's most convenient for everyone.  I'm make the changes to llvm myself,
one per bugfix and then the inclusion of _GLIBCXX_DEBUG if we decide to
go ahead with it.

This should probably happen after the subversion migration, though I may
commit some bugfixes before that.  It would be helpful to have a more
precise projection of when the conversion will happen.

                                                   -Dave