GCC 4.8 introduced two helpful features for debugging and diagnostics. First is a memory sanitizer, and second is a thread sanitizer. Memory saniter acts a lot like dmalloc or Valgrind and is invoked with -fsanitizer=memory. Thread sanitizer is a lot like Helgrind is invoked with -fsanitizer=thread. There are numerous benefits to finding memory and threading problems early in the development process, and not letting the errors creep into production (libupnp is a perfect example). References: http://gcc.gnu.org/gcc-4.8/changes.html, https://code.google.com/p/address-sanitizer/, https://code.google.com/p/data-race-test/wiki/ThreadSanitizer, and http://llvm.org/devmtg/2012-11/Serebryany_TSan-MSan.pdf.
I've tried that but currently the sanitizer people did not understand that it is a good idea to check on a per-feature base. Perhaps, if you can convince them to follow a sensible approach to support different targets *by means of probed features* we can come back and try to add support for using libsanitizer. https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01014.html http://comments.gmane.org/gmane.comp.compilers.llvm.cvs/184974 (for your amusement).