[0/6,C++] Drop -fpermissive hack, enable -Werror
Commit Message
On 11/19/2015 11:27 AM, Yao Qi wrote:
> Pedro Alves <palves@redhat.com> writes:
>
>> I was planning on committing it as soon as I got positive
>> reviews, which seems like I have now. :-) Do you see a reason to
>> hold it for now?
>
> No, I don't. Looks we still need --enable-build-with-cxx to turn C++
> mode on.
Yeah, my plan here was to "lock" (*) ports to C++ mode one by one, as soon
as they build in C++ mode. Actually, I think a negative/reverse list is even
better. This allows keeping track of ports/hosts people really still care
about, and, gives us an easy defined stopping point (when the list is clear).
What would you think of this approach?
I should probably move this to a separate thread, push this to a branch on
sourceware.org (to collect a better initial set of still-needs-conversion-work
hosts, with community help) and announce the intent on the gdb@ list, for
wider visibility/discussion.
(*) - For "locked" ports, one can still force C mode meanwhile
with --enable-build-with-cxx=no, until all ports are converted and we
decide to drop C mode.
---
From b60a477edf5b58a950a9ddf2d1520f95874a1089 Mon Sep 17 00:00:00 2001
From: Pedro Alves <palves@redhat.com>
Date: Thu, 19 Nov 2015 14:40:04 +0000
Subject: [PATCH] Default to building in C++ mode
... except on hosts/targets that haven't been converted yet.
gdb/ChangeLog:
2015-11-19 Pedro Alves <palves@redhat.com>
* build-with-cxx.m4 (GDB_AC_BUILD_WITH_CXX): Default to yes unless
building on some hosts.
* configure: Renegerate.
gdb/gdbserver/ChangeLog:
2015-11-19 Pedro Alves <palves@redhat.com>
* configure: Renegerate.
---
gdb/build-with-cxx.m4 | 18 ++++++++++++++++--
gdb/configure | 17 +++++++++++++++--
gdb/gdbserver/configure | 17 +++++++++++++++--
3 files changed, 46 insertions(+), 6 deletions(-)
Comments
Pedro Alves <palves@redhat.com> writes:
> Yeah, my plan here was to "lock" (*) ports to C++ mode one by one, as soon
> as they build in C++ mode. Actually, I think a negative/reverse list is even
> better. This allows keeping track of ports/hosts people really still care
> about, and, gives us an easy defined stopping point (when the list is clear).
> What would you think of this approach?
Yes, this approach is OK to me. However, as you said, we need to
announce this on gdb@ first. Before we build GDB in C++ mode for some
hosts, we need to test it. IIRC, we didn't test GDB built in C++
before.
Another thing in my mind is the release schedule. We have two months,
but people are off around Christmas and New Year. Do we want GDB 8.0
built in C++ in default in some hosts, such as linux? I am not sure.
>
> I should probably move this to a separate thread, push this to a branch on
> sourceware.org (to collect a better initial set of still-needs-conversion-work
> hosts, with community help) and announce the intent on the gdb@ list, for
> wider visibility/discussion.
Yes, let's do that.
> ---
> gdb/build-with-cxx.m4 | 18 ++++++++++++++++--
> gdb/configure | 17 +++++++++++++++--
> gdb/gdbserver/configure | 17 +++++++++++++++--
> 3 files changed, 46 insertions(+), 6 deletions(-)
>
> diff --git a/gdb/build-with-cxx.m4 b/gdb/build-with-cxx.m4
> index b6284fd..03ff54d 100644
> --- a/gdb/build-with-cxx.m4
> +++ b/gdb/build-with-cxx.m4
> @@ -21,6 +21,21 @@ dnl allowing a user to build with a C++ compiler.
>
> AC_DEFUN([GDB_AC_BUILD_WITH_CXX],
> [
> + # The "doesn't support C++ yet" hall of shame.
> + case $host in
> + *-*aix* | \
> + *-*go32* | \
> + *-*darwin* | \
> + *-*solaris* | \
> + *-*nto* | \
> + *-*bsd* | \
> + xtensa*-*-linux* | \
Why do we especially exclude xtensa*-*-linux* from building in C++ mode?
On 11/20/2015 09:46 AM, Yao Qi wrote:
> Pedro Alves <palves@redhat.com> writes:
>
>> Yeah, my plan here was to "lock" (*) ports to C++ mode one by one, as soon
>> as they build in C++ mode. Actually, I think a negative/reverse list is even
>> better. This allows keeping track of ports/hosts people really still care
>> about, and, gives us an easy defined stopping point (when the list is clear).
>> What would you think of this approach?
>
> Yes, this approach is OK to me. However, as you said, we need to
> announce this on gdb@ first. Before we build GDB in C++ mode for some
> hosts, we need to test it. IIRC, we didn't test GDB built in C++
> before.
On my machine (x86_64 Fedora 20), C++ mode has no regressions compared to C mode.
If C++ is flipped to on by default on (e.g.) x86_64 GNU/Linux, then the x86_64 GNU/Linux
buildbot builders will automatically start testing in C++ mode too. If we do this,
then the Fedora builder (Fedora-x86_64-cxx-build-m64) that is specifically building
with --enable-build-with-cxx should be flipped to build with --enable-build-with-cxx=no,
to catch C mode regressions, for as long as we support C mode.
>
> Another thing in my mind is the release schedule. We have two months,
> but people are off around Christmas and New Year. Do we want GDB 8.0
> built in C++ in default in some hosts, such as linux? I am not sure.
Can't see why not. But we can always flip back to C for the release.
>
>>
>> I should probably move this to a separate thread, push this to a branch on
>> sourceware.org (to collect a better initial set of still-needs-conversion-work
>> hosts, with community help) and announce the intent on the gdb@ list, for
>> wider visibility/discussion.
>
> Yes, let's do that.
OK, I'll try to find some time to do it.
>> AC_DEFUN([GDB_AC_BUILD_WITH_CXX],
>> [
>> + # The "doesn't support C++ yet" hall of shame.
>> + case $host in
>> + *-*aix* | \
>> + *-*go32* | \
>> + *-*darwin* | \
>> + *-*solaris* | \
>> + *-*nto* | \
>> + *-*bsd* | \
>> + xtensa*-*-linux* | \
>
> Why do we especially exclude xtensa*-*-linux* from building in C++ mode?
Just because that one I know for sure doesn't build in C++ mode
yet -- I have a patch from Simon in my github C++ branch that fixes
gdb/xtensa-linux-nat.c in C++ mode, which is not upstream yet.
Thanks,
Pedro Alves
Pedro Alves <palves@redhat.com> writes:
> On my machine (x86_64 Fedora 20), C++ mode has no regressions compared
> to C mode.
I compared the test result on native arm and aarch64 gdb, there is no
regression either.
> If C++ is flipped to on by default on (e.g.) x86_64 GNU/Linux, then
> the x86_64 GNU/Linux
> buildbot builders will automatically start testing in C++ mode too.
> If we do this,
> then the Fedora builder (Fedora-x86_64-cxx-build-m64) that is
> specifically building
> with --enable-build-with-cxx should be flipped to build with
> --enable-build-with-cxx=no,
> to catch C mode regressions, for as long as we support C mode.
>
OK, that is fine to me. After we start to build GDB in C++ mode on some
hosts, I hope we don't have to support both modes too long. According the
c++ conversion in gcc, ENABLE_BUILD_WITH_CXX on configure was added in
2009, and was removed on 2012.
On 11/24/2015 11:01 AM, Yao Qi wrote:
> Pedro Alves <palves@redhat.com> writes:
>
>> On my machine (x86_64 Fedora 20), C++ mode has no regressions compared
>> to C mode.
>
> I compared the test result on native arm and aarch64 gdb, there is no
> regression either.
Great, thanks!
>> If C++ is flipped to on by default on (e.g.) x86_64 GNU/Linux, then
>> the x86_64 GNU/Linux
>> buildbot builders will automatically start testing in C++ mode too.
>> If we do this,
>> then the Fedora builder (Fedora-x86_64-cxx-build-m64) that is
>> specifically building
>> with --enable-build-with-cxx should be flipped to build with
>> --enable-build-with-cxx=no,
>> to catch C mode regressions, for as long as we support C mode.
>>
>
> OK, that is fine to me. After we start to build GDB in C++ mode on some
> hosts, I hope we don't have to support both modes too long. According the
> c++ conversion in gcc, ENABLE_BUILD_WITH_CXX on configure was added in
> 2009, and was removed on 2012.
Wow, that long? I seriously hope we move faster. All depends on the help
we get though...
Thanks,
Pedro Alves
On 11/20/2015 11:21 AM, Pedro Alves wrote:
>>> >> I should probably move this to a separate thread, push this to a branch on
>>> >> sourceware.org (to collect a better initial set of still-needs-conversion-work
>>> >> hosts, with community help) and announce the intent on the gdb@ list, for
>>> >> wider visibility/discussion.
>> >
>> > Yes, let's do that.
> OK, I'll try to find some time to do it.
>
Now done:
https://sourceware.org/ml/gdb/2015-11/msg00035.html
Thanks,
Pedro Alves
> Wow, that long? I seriously hope we move faster. All depends on the help
> we get though...
I'll try to move as quickly as I can, but some targets might be
a bit difficult for us, because we now have to build a C++ compiler,
which is not completely obvious (I'm thinking AIX or LynxOS).
@@ -21,6 +21,21 @@ dnl allowing a user to build with a C++ compiler.
AC_DEFUN([GDB_AC_BUILD_WITH_CXX],
[
+ # The "doesn't support C++ yet" hall of shame.
+ case $host in
+ *-*aix* | \
+ *-*go32* | \
+ *-*darwin* | \
+ *-*solaris* | \
+ *-*nto* | \
+ *-*bsd* | \
+ xtensa*-*-linux* | \
+ null)
+ enable_build_with_cxx=no ;;
+ *)
+ enable_build_with_cxx=yes ;;
+ esac
+
AC_ARG_ENABLE(build-with-cxx,
AS_HELP_STRING([--enable-build-with-cxx], [build with C++ compiler instead of C compiler]),
[case $enableval in
@@ -28,8 +43,7 @@ AC_DEFUN([GDB_AC_BUILD_WITH_CXX],
;;
*)
AC_MSG_ERROR([bad value $enableval for --enable-build-with-cxx]) ;;
- esac],
- [enable_build_with_cxx=no])
+ esac])
if test "$enable_build_with_cxx" = "yes"; then
COMPILER='$(CXX)'
@@ -5001,6 +5001,21 @@ program_transform_name=`$as_echo "$program_transform_name" | sed "$ac_script"`
# See if we are building with C++, and substitute COMPILER.
+ # The "doesn't support C++ yet" hall of shame.
+ case $host in
+ *-*aix* | \
+ *-*go32* | \
+ *-*darwin* | \
+ *-*solaris* | \
+ *-*nto* | \
+ *-*bsd* | \
+ xtensa*-*-linux* | \
+ null)
+ enable_build_with_cxx=no ;;
+ *)
+ enable_build_with_cxx=yes ;;
+ esac
+
# Check whether --enable-build-with-cxx was given.
if test "${enable_build_with_cxx+set}" = set; then :
enableval=$enable_build_with_cxx; case $enableval in
@@ -5009,8 +5024,6 @@ if test "${enable_build_with_cxx+set}" = set; then :
*)
as_fn_error "bad value $enableval for --enable-build-with-cxx" "$LINENO" 5 ;;
esac
-else
- enable_build_with_cxx=no
fi
@@ -4813,6 +4813,21 @@ fi
# See if we are building with C++, and substitute COMPILER.
+ # The "doesn't support C++ yet" hall of shame.
+ case $host in
+ *-*aix* | \
+ *-*go32* | \
+ *-*darwin* | \
+ *-*solaris* | \
+ *-*nto* | \
+ *-*bsd* | \
+ xtensa*-*-linux* | \
+ null)
+ enable_build_with_cxx=no ;;
+ *)
+ enable_build_with_cxx=yes ;;
+ esac
+
# Check whether --enable-build-with-cxx was given.
if test "${enable_build_with_cxx+set}" = set; then :
enableval=$enable_build_with_cxx; case $enableval in
@@ -4821,8 +4836,6 @@ if test "${enable_build_with_cxx+set}" = set; then :
*)
as_fn_error "bad value $enableval for --enable-build-with-cxx" "$LINENO" 5 ;;
esac
-else
- enable_build_with_cxx=no
fi