I believe things are in a state now where it makes sense for folks to do
periodic testing with --enable-expensive-checks to check for C++ library
misuse. Already the last couple of weeks I've fixed several of these kinds
of bugs that were introduced with new code.
It might make sense to configure at least one of the nightly testers to build
with --enable-expensive-checks and uncover these problems quickly. I'm
having a heck of a time getting through a build-test cycle with a Debug+Checks
compiler because it keeps falling over due to C++ library bugs from new code.
I've got some significant register coalescing changes in the pipeline and I
need to test them thoroughly before I commit. I also need to keep them
current so I need to do frequent updates. This gets hard when updates
break the compiler. These errors are usually trivial to fix as the problem is
obvious from the GLIBCXX_DEBUG error output. It's just a matter of doing
a build and test with --enable-expensive-checks. Most of the problems
happen during llvm-gcc bootstrap so it's not even the case that the full
testsuite needs to be run. Just a few sanity checks.
-Dave
Hi David, On Tuesday 7 August 2007 21:15:03 David Greene wrote:> I believe things are in a state now where it makes sense for folks to do > periodic testing with --enable-expensive-checks to check for C++ library > misuse. Already the last couple of weeks I've fixed several of these kinds > of bugs that were introduced with new code.I see that the way of constructing a CallInst was changed to avoid problems with --enable-expensive-checks, but it looks like InvokeInst was not changed. Ciao, Duncan.
On Wednesday 22 August 2007 18:33, Duncan Sands wrote:> I see that the way of constructing a CallInst was changed to avoid problems > with --enable-expensive-checks, but it looks like InvokeInst was not > changed.Yep, I've already got a patch for that. It's in testing now and I hope to commit it tomorrow. -Dave