Hi Stephen,
  I discussed the USE=debug here (https://bugs.gentoo.org/show_bug.cgi?id=482348) and it is denied by portage maintainers because it is not only a debug addition but a whole API change. We have to live with:

mkdir -p /etc/portage/env
echo 'EXTRA_ECONF="--with-pydebug"' > /etc/portage/env/pydebug.conf
echo dev-lang/python pydebug.conf >> /etc/portage/package.env


The above what I had originally. Yesterday I tried even:

# cat /etc/portage/env/pydebug.conf 
EXTRA_ECONF="--with-pydebug --without-pymalloc --with-valgrind"
#

but I don't know what the valgrind option really does and, whether that means:
a) python will run itself under valgrind, don't both doing it yourself
b) you don't have to bother with uncommenting the lines in valgrind.supp
c) "make install" will install the valgrind.supp but you have to edit it on your own
d) you may use valgrind but don't use other tool replacing malloc(), like electric fence, DUMA, etc.

Or some combination of them? :( The Readme.valgrind does not answer this at all.

I let DUMA inspect "emerge boost" run overnight but my computer stopped responding (16GB RAM).

I tried only gcc-4.7.3 and python-2.7.5-r2.

CFLAGS="-ggdb -pipe -msse  -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -msse4 -mavx -maes -mpclmul -mpopcnt -march=corei7-avx"
CXXFLAGS="${CFLAGS}"


Per comment from Charles-François, so you mean that this single-bit change won't be caught by valgrind, right? Why does not memtest86+ detect that? Could python when compiled with the --with-pydebug print also physical, hardware address of the wrong value? That would be really helpful here! Thanks.