[PATCH] Enable C++11 starting with gcc 4.8 (was: Re: [PATCH 1/3] Introduce gdb::unique_ptr)

[Pedro Alves <palves@redhat.com>]

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.

But,
 https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
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:

 http://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx.html

To recap:

> Conceptually, the gdb::unique_ptr patch (this thread) does:
> 
> #if HAVE_STD_UNIQUE_PTR
> 
> // just use it
> 
> #else
> 
> // write replacement
> 
> #endif
> 
> 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)

Thanks,
Pedro Alves