The ptrace args/return types detection doesn't work properly in C++
mode, on non-GNU/Linux hosts.  For example, on gcc70 (NetBSD 5.1),
where the prototype is:

 int ptrace(int, __pid_t, void*, int);

configure misdetects it as:

 $ grep PTRACE_TYPE config.h
 #define PTRACE_TYPE_ARG1 int
 #define PTRACE_TYPE_ARG3 int *
 #define PTRACE_TYPE_ARG4 int
 /* #undef PTRACE_TYPE_ARG5 */
 #define PTRACE_TYPE_RET int

resulting in:

 ../../src/gdb/amd64bsd-nat.c: In function 'void amd64bsd_fetch_inferior_registers(target_ops*, regcache*, int)':
 ../../src/gdb/amd64bsd-nat.c:56: warning: dereferencing type-punned pointer will break strict-aliasing rules
 ../../src/gdb/amd64bsd-nat.c: In function 'void amd64bsd_store_inferior_registers(target_ops*, regcache*, int)':
 ../../src/gdb/amd64bsd-nat.c:104: warning: dereferencing type-punned pointer will break strict-aliasing rules
 ../../src/gdb/amd64bsd-nat.c:110: warning: dereferencing type-punned pointer will break strict-aliasing rules

We could address this [1], however despite ptrace.m4's claim:

 # Needs to be tested in C++ mode, to detect whether we need to cast
 # the first argument to enum __ptrace_request.

it appears that there's actually no need to test in C++ mode.  Always
running the ptrace tests in C mode works just the same on GNU/Linux.

I remember experimenting with several different ways to handle the
original issue back then, and maybe that was needed in some other
attempt and then I didn't realize it ended up not really necessary.

Confirmed that this fixes the NetBSD 5.1 C++ build, and confirmed that
C and C++ builds on Fedora 23 are unaffected.

[1] - https://sourceware.org/ml/gdb-patches/2016-04/msg00374.html

gdb/ChangeLog:
2016-04-18  Pedro Alves  <palves@redhat.com>

	* ptrace.m4 (GDB_AC_PTRACE): Don't run tests in C++ mode.
	* configure: Regenerate.

gdb/gdbserver/ChangeLog:
2016-04-18  Pedro Alves  <palves@redhat.com>

	* configure: Regenerate.