This is the mail archive of the
mailing list for the GDB project.
[PATCH] Enable C++11 starting with gcc 4.8 (was: Re: [PATCH 1/3] Introduce gdb::unique_ptr)
On 10/12/2016 11:28 AM, Pedro Alves wrote:
> On 10/12/2016 09:11 AM, Metzger, Markus T wrote:
>> A simple and pragmatic solution would be a patch to add -std=c++11
>> to GDB's compiler options. Pedro already mentioned it but I'm afraid it
>> got lost.
> Looks like it, yes. As I've explained, we can't do it on src/gdb/
> alone, because the CXX make variable is passed down from the top level,
> which would override whatever we set in gdb/'s configure/Makefile.
> I want to give it a try, though. It just requires time and getting
> the patch into gcc and merged back. I don't think that should hold
> back the proposed series (or pieces of it).
> I wasn't originally meaning to unconditionally add -std=c++11 though,
> but instead to only add it if the compiler supports it, in order
> to conservatively still support C++03-only compilers.
OK, I spend a few hours tonight working on this.
I was thinking ahead that we'll like have other C++ libraries in
the top level that we'd be using (code shared with gcc, and also
gdbserver moving to top level, maybe parts split to libraries, etc.).
And I was mistakenly under the impression that all subdirs would have to be
built with the same C++ dialect, given the C++11 ABI change. I.e.,
use the same dialect throughout to avoid ABI conflicts.
So I first wrote a patch that had the top level configure source a
file in each subdir that would tell the top level the minimum and
maximum C++ dialect versions each subdir supported, and then the
top level could compute the dialect to set CXX to.
explains how mixing dialects is not really a problem.
So I was over complicating.
However, the issue with CXX being passed by the top level overriding
whatever gdb's configure/Makefile decide to set CXX to is
real though. But I solved it in a different way, all within gdb/
Instead of having configure append -std=xxx to CXX, simply set a
separate CXX_DIALECT variable, and tweak the Makefile to use
"$CXX CXX_DIALECT" to compile/link.
In order to detect whether the compiler supports C++11 (i.e.,
if we're using gcc 4.8 or later, or a clang that supports C++11,
etc.), I'm reusing a macro from the GNU Autoconf Archive, at:
> Conceptually, the gdb::unique_ptr patch (this thread) does:
> #if HAVE_STD_UNIQUE_PTR
> // just use it
> // write replacement
> The replacement is fully functional.
> If I push the patch in now, HAVE_STD_UNIQUE_PTR will only be true
> when compiling GDB with GCC >= 6.x, because G++ 6.1 targets G++14
> by default, which is a superset of C++11. The replacement
> works with all other GCCs. It'd be possible to make
> HAVE_STD_UNIQUE_PTR be true with GCC >= 4.x too, but nobody wrote
> that patch yet.
So I wrote that patch now.
IOW, the idea is that gdb::unique_ptr maps to C++11
std::unique_ptr iff C++11 is available and to a replacement
otherwise. The C++03 replacement works just as well, however
the C++11 version catches more bugs at compile time.
Full C++11 support is available starting with gcc 4.8, however
only gcc 6.1 switched to default to C++11 (C++14, actually).
So for gcc 4.8 till gcc 6.1, we need to explicitly pass -std=gnu++11
to the compiler. That's what the patch I wrote tonight does.
I'll send it as reply to this email. Two patches actually.
> But if we agree to go full-on C++11, then I'll be more than
> happy to make gdb's configure error out on non-C++11 compilers.
The patches add this to configure:
AX_CXX_COMPILE_STDCXX(11, , optional)
"optional" means that not having a C++11 compiler is OK.
IOW, "try to enable C++11 iff possible".
If we decide to _require_ C++11 (i.e., drop support for C++03-only), then
it's a simple matter of changing that to:
AX_CXX_COMPILE_STDCXX(11, , mandatory)