[PATCH] Fix --enable-checking of libcpp, add valgrind workarounds

Jeff Law law@redhat.com
Wed Feb 27 22:06:00 GMT 2013

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  <jakub@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.


More information about the Gcc-patches mailing list