[PATCH] Fix --enable-checking of libcpp, add valgrind workarounds
Wed Feb 27 22:06:00 GMT 2013
On 02/27/2013 09:08 AM, Jakub Jelinek wrote:
> 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
> 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 <email@example.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.
More information about the Gcc-patches