Merge in the COMPVBITS branch to the trunk. This is a big change to
Memcheck, replacing the 9-bits-per-byte shadow memory representation to a
2-bits-per-byte representation (with possibly a little more on the side) by
taking advantage of the fact that extremely few memory bytes are partially
defined.
For the SPEC2k benchmarks with "test" inputs, this speeds up Memcheck by a
(geometric mean) factor of 1.20, and reduces the size of shadow memory by a
(geometric mean) factor of 4.26.
At the same time, Addrcheck is removed. It hadn't worked for quite some
time, and with these improvements in Memcheck its raisons-d'etre have
shrivelled so much that it's not worth the effort to keep around. Hooray!
Nb: this code hasn't been tested on PPC. If things go wrong, look first in
the fast stack-handling functions (eg. mc_new_mem_stack_160,
MC_(helperc_MAKE_STACK_UNINIT)).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5791 a5019735-40e9-0310-863c-91ae7b9d1cf9
diff --git a/docs/xml/FAQ.xml b/docs/xml/FAQ.xml
index 915aede..04491db 100644
--- a/docs/xml/FAQ.xml
+++ b/docs/xml/FAQ.xml
@@ -159,7 +159,7 @@
<para>Another possibility is that your program has a bug and
erroneously jumps to a non-code address, in which case you'll get a
- SIGILL signal. Memcheck/Addrcheck may issue a warning just before
+ SIGILL signal. Memcheck may issue a warning just before
this happens, but they might not if the jump happens to land in
addressable memory.</para>
</answer>
@@ -470,7 +470,7 @@
<qandaentry id="faq.deflost">
<question id="q-deflost">
- <para>With Memcheck/Addrcheck's memory leak detector, what's the
+ <para>With Memcheck's memory leak detector, what's the
difference between "definitely lost", "possibly lost", "still
reachable", and "suppressed"?</para>
</question>