The c++tools configure fragments need to be built with a C++ compiler.
In addition, the stand-alone server uses diagnostic mechanisms in common
with GCC, but needs to define implementations for gcc_assert and
supporting output functions.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
PR c++/98821 - modules : c++tools configures with CC but code fragments assume CXX.
PR c++/98821
c++tools/ChangeLog:
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Configure using C++. Pull logic to
detect enabled checking modes; default to release
checking.
* server.cc (AI_NUMERICSERV): Define a fallback value.
(gcc_assert): New.
(gcc_unreachable): New.
(fancy_abort): Only build when checking is enabled.
Co-authored-by: Jakub Jelinek <jakub@redhat.com>
When breaking out the sample server from the gcc/cp directory, it lost
its check for mmap, and the sample resolver just assumed it was there.
Fixed thusly. The non-mapping paths in module.cc weren't (recently)
excercised, and led to a signedness warning. Finally I'd missed
c++tools's config.h.in in the gcc_update script. There I took the
opportunity of adding a 'tools' segment of the dependency lists.
PR bootstrap/98300
contrib/
* gcc_update: Add c++tools/config.h.in.
c++tools/
* configure.ac: Check for sys/mman.h.
* resolver.cc: Don't assume mmap, O_CLOEXEC are available. Use
xmalloc.
* config.h.in: Regenerated.
* configure: Regenerated.
gcc/cp/
* module.cc: Fix ::read, ::write result signedness comparisons.
Part of our module implementation adds a sample mapper server, the
guts of which are used by the default in-process mapping of cc1plus.
Rather than add another executable to gcc/cp/, this creates a new
c++tools directory where this and any other c++ tools might live.
The toplevel changes are a subsequent commit, because ... git.
c++tools/ChangeLog:
* Makefile.in: New.
* config.h.in: New.
* configure: New.
* configure.ac: New.
* resolver.cc: New.
* resolver.h: New.
* server.cc: New.
