search for: d_glibcxx_debug

I just made a patch to our local llvm build here to pass -D_GLIBCXX_DEBUG when building llvm. This switch turns on debug code in libstdc++ that checks for various violations. We've already discovered several llvm bugs with it. Should I commit a change back to the official sources? It will almost certainly cause tests to fail, but that's a GOOD thing....

On Thu, 7 Jun 2007, David A. Greene wrote: > I just made a patch to our local llvm build here to pass -D_GLIBCXX_DEBUG when > building llvm. This switch turns on debug code in libstdc++ that checks for > various violations. We've already discovered several llvm bugs with it. > Should I commit a change back to the official sources? It will almost > certainly cause tests to fail, but that's a G...

I'm continuing my quest to integrate _GLIBCXX_DEBUG into the config system. I now have things at a point where I can configure llvm to build with -D_GLIBCXX_DEBUG and the llvm-gcc will pick up the correct CPPFLAGS automatically. One thing I noticed in the llvm Makefile.rules is this: # If DISABLE_ASSERTIONS=1 is specified (make command line or configured), # then disable assertions by defining the appropriate preprocessor symbols. ifdef DISABLE_ASSERTIONS...

Hi David, On Mon, 2007-06-25 at 17:43 -0500, David A. Greene wrote: > I'm continuing my quest to integrate _GLIBCXX_DEBUG into the config system. > I now have things at a point where I can configure llvm to build with > -D_GLIBCXX_DEBUG and the llvm-gcc will pick up the correct CPPFLAGS > automatically. Okay. > > One thing I noticed in the llvm Makefile.rules is this: > > # If DISABLE_ASSERTIONS=1 is specified (make command line or configured), > # then disable assertions by defining the appropriate preproces...

.../projects/llvm-project.modified/llvm/trunk/utils/TableGen -I/tmp/ptmp/dag/build.llvm.modified.debug/include -I/users/dag/projects/llvm-project.modified/llvm/trunk/include -I/tmp/ptmp/dag/build.llvm.modified.debug/include -I/users/dag/projects/llvm-project.modified/llvm/trunk/include -D_DEBUG -D_GLIBCXX_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -g -Woverloaded-virtual -Wall -W -Wwrite-strings -Wunused -Wno-unused-parameter -g -rpath /tmp/ptmp/dag/build.llvm.modified.debug/Debug+Checks/bin -export-dynamic -L/tmp/ptmp/dag/build.llvm.modified.debug/Debug+Checks/lib -L/tmp/ptmp/dag/build.llvm.modifie...

On May 14, 2009, at 4:56 AM, Jay Foad wrote: > 2009/4/1 Chris Lattner <clattner at apple.com>: >> As far API design goes, we're in a mixed state. I'd strongly prefer >> to get rid of std::vector from the various interfaces, f.e. >> creating a >> constant array currently requires passing in an std::vector. For >> these sorts of interfaces, we

2009/4/1 Chris Lattner <clattner at apple.com>: > As far API design goes, we're in a mixed state.  I'd strongly prefer > to get rid of std::vector from the various interfaces, f.e. creating a > constant array currently requires passing in an std::vector.  For > these sorts of interfaces, we should migrate to passing in a "Constant > *const* / unsigned" pair.

...passed to the compiler(s), should be avoided as identifiers for naming variables, constants, enum members, macros etc. [2845/3381] Building CXX object tools/clang/lib/Tooling/CMakeFiles/clangTooling.dir/Execution.cpp.o FAILED: /usr/local/gcc-latest/bin/g++-latest -DEXPENSIVE_CHECKS -D_DEBUG -D_GLIBCXX_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/clang/lib/Frontend/Rewrite -I/sw/src/clang_llvm_dev/clang/lib/Frontend/Rewrite -I/sw/src/clang_llvm_dev/clang/include -Itools/clang/include -Iinclude -I/sw/src/clang_llvm_dev/llvm_trunk/include -fopt-inf...

...>> [89/2690] Building CXX object >> >> lib/Support/CMakeFiles/LLVMSupport.dir/SourceMgr.cpp.o >> >> FAILED: lib/Support/CMakeFiles/LLVMSupport.dir/SourceMgr.cpp.o >> >> /usr/lib/ccache/g++-8 -DEXPENSIVE_CHECKS -DGTEST_HAS_RTTI=0 -D_DEBUG >> >> -D_GLIBCXX_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS >> >> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Support >> >> -I/home/jayfoad2/git/llvm-project/llvm/lib/Support -Iinclude >> >> -I/home/jayfoad2/git/llvm-project/llvm/incl >> >> ude -fPIC -fvisibility-i...

...dear. That's a bit of a flaw in the plan. I suppose the solution is to switch to SmallVector whenever this might be a problem. I'm a bit concerned that any new &empty[0] problems that are introduced will go unnoticed. With GNU libstdc++ they aren't diagnosed unless you build with -D_GLIBCXX_DEBUG (or ENABLE_EXPENSIVE_CHECKS=1). For now I'm testing with ENABLE_EXPENSIVE_CHECKS=1, and it is indeed catching lots of errors! > (though it is safe for smallvector). DR 464 proposes a new data() method. I'd suggest implementing that in SmallVector, instead of relying on the relaxed che...

...-DLLVM_ENABLE_EXPENSIVE_CHECKS=ON ~/git/llvm-project/llvm/ && ninja ... [89/2690] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/SourceMgr.cpp.o FAILED: lib/Support/CMakeFiles/LLVMSupport.dir/SourceMgr.cpp.o /usr/lib/ccache/g++-8 -DEXPENSIVE_CHECKS -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GLIBCXX_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Support -I/home/jayfoad2/git/llvm-project/llvm/lib/Support -Iinclude -I/home/jayfoad2/git/llvm-project/llvm/incl ude -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++14 -Wall -Wextra -Wno-unused-par...

...llvm/ && ninja >> ... >> [89/2690] Building CXX object >> lib/Support/CMakeFiles/LLVMSupport.dir/SourceMgr.cpp.o >> FAILED: lib/Support/CMakeFiles/LLVMSupport.dir/SourceMgr.cpp.o >> /usr/lib/ccache/g++-8 -DEXPENSIVE_CHECKS -DGTEST_HAS_RTTI=0 -D_DEBUG >> -D_GLIBCXX_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS >> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Support >> -I/home/jayfoad2/git/llvm-project/llvm/lib/Support -Iinclude >> -I/home/jayfoad2/git/llvm-project/llvm/incl >> ude -fPIC -fvisibility-inlines-hidden -Werror=date-time -std...