Fun with _GLIBCXX_DEBUG

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

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.

Ooh, subtle bugs found and fixed are definitely good.

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.

Ah, ok.

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.

No, I don't think we do. I think a configure option is best.

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.

Okay. I think the right way to do this is to make it a configure option when building LLVM. Then make sure the option gets propagated down and shows up in the "llvm-config --cflags" option.

Once that is done, clients of the LLVM libs can know to build with the option. The next step is to switch llvm-gcc to actually use llvm-config --cflags. Basically change this line:

CPPFLAGS = @CPPFLAGS@ -DENABLE_LLVM -D__STDC_LIMIT_MACROS

to be:

CPPFLAGS := @CPPFLAGS@ -DENABLE_LLVM $(shell $(LLVMBINPATH)/llvm-config --cflags)

Something close to that should work.

So here are the questions we should wrestle with before making any changes:
- Do we want _GLIBCXX_DEBUG enabled in debug builds by default?

Nope

- Should it be a configure option?

Yep!

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

Probably just a configure option on the llvm libs.

- What's the strategy for llvm-gcc?

llvm-gcc should transparently follow the llvm libraries.

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.

For now, please prepare a patch and send it to llvm-commits. Thanks for working on this!

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.

I don't think this needs to be tied to the svn migration,

-Chris