On 02/27/2013 09:08 AM, Jakub Jelinek wrote:
Hi!
I've noticed that libcpp/ uses --enable-checking in configure in incompatible
way from gcc/, as the configure options are passed to both, we'd better make
them compatible. In particular, libcpp would be built with checking even
e.g. when configured with --enable-checking=release, on the other side
wouldn't do any checking when configured without anything but DEV-PHASE is
experimental.
Fixed thusly, so that libcpp checking is enabled any time gcc
ENABLE_CHECKING (aka misc checking) is enabled. Additionally I've added
handling for valgrind checking, which doesn't like memory pointed just
through interior pointers and complains about that. So, when configured
e.g. with --enable-checking=yes,valgrind or similar, libcpp will put the
_cpp_buff structure at the start rather than end of the allocated area and
valgrind won't complain in that case.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2013-02-27 Jakub Jelinek <ja...@redhat.com>
* configure.ac: Don't define ENABLE_CHECKING whenever
--enable-checking is seen, instead use similar --enable-checking=yes
vs. --enable-checking=release default as gcc/ subdir has and
define ENABLE_CHECKING if ENABLE_CHECKING is defined in gcc/.
Define ENABLE_VALGRIND_CHECKING if requested.
* lex.c (new_buff): If ENABLE_VALGRIND_CHECKING, put _cpp_buff
struct first in the allocated buffer and result->base after it.
(_cpp_free_buff): If ENABLE_VALGRIND_CHECKING, free buff itself
instead of buff->base.
* config.in: Regenerated.
* configure: Regenerated.
Presumably there's a good reason why we don't put __cpp_buff at the
start of the structure all the time? From a purely maintenance
standpoint that seems better
Approved as is. If you want to move cpp_buff at the start of the
structure, I'll pre-approve that as well.
jeff
