diff mbox series

[RFC] libstdc++: Make --enable-libstdcxx-backtrace=auto default to yes

Message ID 20230823160322.237140-1-jwakely@redhat.com
State New
Headers show
Series [RFC] libstdc++: Make --enable-libstdcxx-backtrace=auto default to yes | expand

Commit Message

Jonathan Wakely Aug. 23, 2023, 4:02 p.m. UTC
Any objections to this? It's a C++23 feture, so should be enabled by
default.

-- >8 --

This causes libstdc++_libbacktrace.a to be built by default. This might
fail on some targets, in which case we can make the 'auto' choice expand
to either 'yes' or 'no' depending on the target.

libstdc++-v3/ChangeLog:

	* acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Default to yes.
	* configure: Regenerate.
---
 libstdc++-v3/acinclude.m4 | 2 +-
 libstdc++-v3/configure    | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Comments

Jonathan Wakely Sept. 1, 2023, 11:16 a.m. UTC | #1
On Wed, 23 Aug 2023 at 17:03, Jonathan Wakely via Libstdc++
<libstdc++@gcc.gnu.org> wrote:
>
> Any objections to this? It's a C++23 feture, so should be enabled by
> default.

I've pushed this to trunk, so let's see what breaks!


>
> -- >8 --
>
> This causes libstdc++_libbacktrace.a to be built by default. This might
> fail on some targets, in which case we can make the 'auto' choice expand
> to either 'yes' or 'no' depending on the target.
>
> libstdc++-v3/ChangeLog:
>
>         * acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Default to yes.
>         * configure: Regenerate.
> ---
>  libstdc++-v3/acinclude.m4 | 2 +-
>  libstdc++-v3/configure    | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
> index b25378eaace..50c808c6b2d 100644
> --- a/libstdc++-v3/acinclude.m4
> +++ b/libstdc++-v3/acinclude.m4
> @@ -5481,7 +5481,7 @@ BACKTRACE_CPPFLAGS="$BACKTRACE_CPPFLAGS -DBACKTRACE_ELF_SIZE=$elfsize"
>
>    AC_MSG_CHECKING([whether to build libbacktrace support])
>    if test "$enable_libstdcxx_backtrace" = "auto"; then
> -    enable_libstdcxx_backtrace=no
> +    enable_libstdcxx_backtrace=yes
>    fi
>    AC_MSG_RESULT($enable_libstdcxx_backtrace)
>    if test "$enable_libstdcxx_backtrace" = "yes"; then
>
Jonathan Wakely Sept. 1, 2023, 4:10 p.m. UTC | #2
On Fri, 1 Sept 2023 at 12:16, Jonathan Wakely <jwakely@redhat.com> wrote:
>
> On Wed, 23 Aug 2023 at 17:03, Jonathan Wakely via Libstdc++
> <libstdc++@gcc.gnu.org> wrote:
> >
> > Any objections to this? It's a C++23 feture, so should be enabled by
> > default.
>
> I've pushed this to trunk, so let's see what breaks!

This modules header broke on aarch64, of course:
FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors)

>
>
> >
> > -- >8 --
> >
> > This causes libstdc++_libbacktrace.a to be built by default. This might
> > fail on some targets, in which case we can make the 'auto' choice expand
> > to either 'yes' or 'no' depending on the target.
> >
> > libstdc++-v3/ChangeLog:
> >
> >         * acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Default to yes.
> >         * configure: Regenerate.
> > ---
> >  libstdc++-v3/acinclude.m4 | 2 +-
> >  libstdc++-v3/configure    | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
> > index b25378eaace..50c808c6b2d 100644
> > --- a/libstdc++-v3/acinclude.m4
> > +++ b/libstdc++-v3/acinclude.m4
> > @@ -5481,7 +5481,7 @@ BACKTRACE_CPPFLAGS="$BACKTRACE_CPPFLAGS -DBACKTRACE_ELF_SIZE=$elfsize"
> >
> >    AC_MSG_CHECKING([whether to build libbacktrace support])
> >    if test "$enable_libstdcxx_backtrace" = "auto"; then
> > -    enable_libstdcxx_backtrace=no
> > +    enable_libstdcxx_backtrace=yes
> >    fi
> >    AC_MSG_RESULT($enable_libstdcxx_backtrace)
> >    if test "$enable_libstdcxx_backtrace" = "yes"; then
> >
Hans-Peter Nilsson Sept. 4, 2023, 4:35 p.m. UTC | #3
I was about to enter a PR for the regression, but as you're
already aware, I'll wait 24 hours to see if this magically
goes away. :]

> On Fri, 1 Sept 2023 at 12:16, Jonathan Wakely <jwakely@redhat.com> wrote:
> >
> > On Wed, 23 Aug 2023 at 17:03, Jonathan Wakely via Libstdc++
> > <libstdc++@gcc.gnu.org> wrote:
> > >
> > > Any objections to this? It's a C++23 feture, so should be enabled by
> > > default.
> >
> > I've pushed this to trunk, so let's see what breaks!
> 
> This modules header broke on aarch64, of course:
> FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors)

And others, according to testresults@ including
powerpc64le-unknown-linux-gnu, x86_64-pc-linux-gnu,
s390x-ibm-linux-gnu, m68k-unknown-linux-gnu,
pru-unknown-elf, and...cris-elf (notably, both "64-bit" and
"32-bit" configurations).

Not sure how much information you have, but for cris-elf,
g++.log shows:

FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors)
Excess errors:
/obj/libstdc++-v3/include/stacktrace:202:24: error: mangling of 'constexpr std::stacktrace_entry::_M_get_info(std::string*, std::string*, int*) const::<lambda(void*, std::stacktrace_entry::uintptr_t, const char*, std::stacktrace_entry::uintptr_t, std::stacktrace_entry::uintptr_t)>::operator void (*)(void*, std::stacktrace_entry::uintptr_t, const char*, std::stacktrace_entry::uintptr_t, std::stacktrace_entry::uintptr_t)() const' as '_ZZNKSt16stacktrace_entry11_M_get_infoEPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES6_PiENKUlPvmPKcmmE_cvPFvS8_mSA_mmEEv' conflicts with a previous mangle
/obj/libstdc++-v3/include/stacktrace:202:24: error: mangling of 'static constexpr void std::stacktrace_entry::_M_get_info(std::string*, std::string*, int*) const::<lambda(void*, std::stacktrace_entry::uintptr_t, const char*, std::stacktrace_entry::uintptr_t, std::stacktrace_entry::uintptr_t)>::_FUN(void*, std::stacktrace_entry::uintptr_t, const char*, std::stacktrace_entry::uintptr_t, std::stacktrace_entry::uintptr_t)' as '_ZZNKSt16stacktrace_entry11_M_get_infoEPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES6_PiENUlPvmPKcmmE_4_FUNES8_mSA_mm' conflicts with a previous mangle
/obj/libstdc++-v3/include/stacktrace:202:24: error: mangling of 'std::stacktrace_entry::_M_get_info(std::string*, std::string*, int*) const::<lambda(void*, std::stacktrace_entry::uintptr_t, const char*, std::stacktrace_entry::uintptr_t, std::stacktrace_entry::uintptr_t)>' as '_ZZNKSt16stacktrace_entry11_M_get_infoEPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES6_PiENKUlPvmPKcmmE_clES8_mSA_mm' conflicts with a previous mangle

So, I *guess* it's some kind of pre-existing mangling foulup
with C++20 in the backtrace-support that just happens to be
ticked off by the module testsuite.  But you probably
already knew that.

brgds, H-P
Hans-Peter Nilsson Sept. 4, 2023, 4:46 p.m. UTC | #4
> Date: Fri, 1 Sep 2023 12:16:40 +0100
> Reply-To: Jonathan Wakely <jwakely@redhat.com>
> 
> On Wed, 23 Aug 2023 at 17:03, Jonathan Wakely via Libstdc++
> <libstdc++@gcc.gnu.org> wrote:
> >
> > Any objections to this? It's a C++23 feture, so should be enabled by
> > default.
> 
> I've pushed this to trunk, so let's see what breaks!
> 
> 
> >
> > -- >8 --
> >
> > This causes libstdc++_libbacktrace.a to be built by default. This might
> > fail on some targets, in which case we can make the 'auto' choice expand
> > to either 'yes' or 'no' depending on the target.
> >
> > libstdc++-v3/ChangeLog:
> >
> >         * acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Default to yes.
> >         * configure: Regenerate.

Incidentally, should check_effective_target_stacktrace in
libstdc++.exp also be adjusted to match; removing the
_GLIBCXX_HOSTED condition?

brgds, H-P
Jonathan Wakely Sept. 4, 2023, 4:48 p.m. UTC | #5
On Mon, 4 Sept 2023 at 17:47, Hans-Peter Nilsson via Libstdc++
<libstdc++@gcc.gnu.org> wrote:
>
> > Date: Fri, 1 Sep 2023 12:16:40 +0100
> > Reply-To: Jonathan Wakely <jwakely@redhat.com>
> >
> > On Wed, 23 Aug 2023 at 17:03, Jonathan Wakely via Libstdc++
> > <libstdc++@gcc.gnu.org> wrote:
> > >
> > > Any objections to this? It's a C++23 feture, so should be enabled by
> > > default.
> >
> > I've pushed this to trunk, so let's see what breaks!
> >
> >
> > >
> > > -- >8 --
> > >
> > > This causes libstdc++_libbacktrace.a to be built by default. This might
> > > fail on some targets, in which case we can make the 'auto' choice expand
> > > to either 'yes' or 'no' depending on the target.
> > >
> > > libstdc++-v3/ChangeLog:
> > >
> > >         * acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Default to yes.
> > >         * configure: Regenerate.
>
> Incidentally, should check_effective_target_stacktrace in
> libstdc++.exp also be adjusted to match; removing the
> _GLIBCXX_HOSTED condition?

No, it should still depend on is_hosted. The acinclude.m4 macro should
check that.
Jonathan Wakely Sept. 6, 2023, 10:30 p.m. UTC | #6
On Mon, 4 Sept 2023 at 17:49, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Mon, 4 Sept 2023 at 17:47, Hans-Peter Nilsson via Libstdc++
> <libstdc++@gcc.gnu.org> wrote:
> >
> > > Date: Fri, 1 Sep 2023 12:16:40 +0100
> > > Reply-To: Jonathan Wakely <jwakely@redhat.com>
> > >
> > > On Wed, 23 Aug 2023 at 17:03, Jonathan Wakely via Libstdc++
> > > <libstdc++@gcc.gnu.org> wrote:
> > > >
> > > > Any objections to this? It's a C++23 feture, so should be enabled by
> > > > default.
> > >
> > > I've pushed this to trunk, so let's see what breaks!
> > >
> > >
> > > >
> > > > -- >8 --
> > > >
> > > > This causes libstdc++_libbacktrace.a to be built by default. This might
> > > > fail on some targets, in which case we can make the 'auto' choice expand
> > > > to either 'yes' or 'no' depending on the target.
> > > >
> > > > libstdc++-v3/ChangeLog:
> > > >
> > > >         * acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Default to yes.
> > > >         * configure: Regenerate.
> >
> > Incidentally, should check_effective_target_stacktrace in
> > libstdc++.exp also be adjusted to match; removing the
> > _GLIBCXX_HOSTED condition?
>
> No, it should still depend on is_hosted. The acinclude.m4 macro should
> check that.

Done in r14-3761-g6de5f5a4fe85bd
Hans-Peter Nilsson Sept. 6, 2023, 11:09 p.m. UTC | #7
> From: Jonathan Wakely <jwakely@redhat.com>
> Date: Wed, 6 Sep 2023 23:30:08 +0100

> On Mon, 4 Sept 2023 at 17:49, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> >
> > On Mon, 4 Sept 2023 at 17:47, Hans-Peter Nilsson via Libstdc++
> > <libstdc++@gcc.gnu.org> wrote:
> > >
> > > > Date: Fri, 1 Sep 2023 12:16:40 +0100
> > > > Reply-To: Jonathan Wakely <jwakely@redhat.com>
> > > >
> > > > On Wed, 23 Aug 2023 at 17:03, Jonathan Wakely via Libstdc++
> > > > <libstdc++@gcc.gnu.org> wrote:
> > > > >
> > > > > Any objections to this? It's a C++23 feture, so should be enabled by
> > > > > default.
> > > >
> > > > I've pushed this to trunk, so let's see what breaks!
> > > >
> > > >
> > > > >
> > > > > -- >8 --
> > > > >
> > > > > This causes libstdc++_libbacktrace.a to be built by default. This might
> > > > > fail on some targets, in which case we can make the 'auto' choice expand
> > > > > to either 'yes' or 'no' depending on the target.
> > > > >
> > > > > libstdc++-v3/ChangeLog:
> > > > >
> > > > >         * acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Default to yes.
> > > > >         * configure: Regenerate.
> > >
> > > Incidentally, should check_effective_target_stacktrace in
> > > libstdc++.exp also be adjusted to match; removing the
> > > _GLIBCXX_HOSTED condition?
> >
> > No, it should still depend on is_hosted. The acinclude.m4 macro should
> > check that.
> 
> Done in r14-3761-g6de5f5a4fe85bd

Aha, that's what you meant.  I thought you meant that just
check_effective_target_stacktrace should be gated on
$is_hosted.

Yeah, it makes sense not to have backtrace enabled by
default for ! $is_hosted.  On the other hand, bare-iron
targets like cris-elf apparently *are* hosted, according to
"#if __STDC_HOSTED__".  I guess I'll have to dig into what
the definition of "hosted" is, because I don't agree by the
layman obvious definition.  Maybe there's a bug to fix.
There sure are many yaks to shave these days.

brgds, H-P
Jonathan Wakely Sept. 6, 2023, 11:10 p.m. UTC | #8
On Thu, 7 Sept 2023 at 00:09, Hans-Peter Nilsson <hp@axis.com> wrote:
>
> > From: Jonathan Wakely <jwakely@redhat.com>
> > Date: Wed, 6 Sep 2023 23:30:08 +0100
>
> > On Mon, 4 Sept 2023 at 17:49, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> > >
> > > On Mon, 4 Sept 2023 at 17:47, Hans-Peter Nilsson via Libstdc++
> > > <libstdc++@gcc.gnu.org> wrote:
> > > >
> > > > > Date: Fri, 1 Sep 2023 12:16:40 +0100
> > > > > Reply-To: Jonathan Wakely <jwakely@redhat.com>
> > > > >
> > > > > On Wed, 23 Aug 2023 at 17:03, Jonathan Wakely via Libstdc++
> > > > > <libstdc++@gcc.gnu.org> wrote:
> > > > > >
> > > > > > Any objections to this? It's a C++23 feture, so should be enabled by
> > > > > > default.
> > > > >
> > > > > I've pushed this to trunk, so let's see what breaks!
> > > > >
> > > > >
> > > > > >
> > > > > > -- >8 --
> > > > > >
> > > > > > This causes libstdc++_libbacktrace.a to be built by default. This might
> > > > > > fail on some targets, in which case we can make the 'auto' choice expand
> > > > > > to either 'yes' or 'no' depending on the target.
> > > > > >
> > > > > > libstdc++-v3/ChangeLog:
> > > > > >
> > > > > >         * acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Default to yes.
> > > > > >         * configure: Regenerate.
> > > >
> > > > Incidentally, should check_effective_target_stacktrace in
> > > > libstdc++.exp also be adjusted to match; removing the
> > > > _GLIBCXX_HOSTED condition?
> > >
> > > No, it should still depend on is_hosted. The acinclude.m4 macro should
> > > check that.
> >
> > Done in r14-3761-g6de5f5a4fe85bd
>
> Aha, that's what you meant.  I thought you meant that just
> check_effective_target_stacktrace should be gated on
> $is_hosted.
>
> Yeah, it makes sense not to have backtrace enabled by
> default for ! $is_hosted.  On the other hand, bare-iron
> targets like cris-elf apparently *are* hosted, according to
> "#if __STDC_HOSTED__".  I guess I'll have to dig into what
> the definition of "hosted" is, because I don't agree by the
> layman obvious definition.  Maybe there's a bug to fix.

I don't think there's a bug. $is_hosted is true for
--enable-hosted-libstdcxx which is on by default.


> There sure are many yaks to shave these days.
>
> brgds, H-P
>
Jonathan Wakely Sept. 6, 2023, 11:11 p.m. UTC | #9
On Thu, 7 Sept 2023 at 00:10, Jonathan Wakely <jwakely@redhat.com> wrote:
>
> On Thu, 7 Sept 2023 at 00:09, Hans-Peter Nilsson <hp@axis.com> wrote:
> >
> > > From: Jonathan Wakely <jwakely@redhat.com>
> > > Date: Wed, 6 Sep 2023 23:30:08 +0100
> >
> > > On Mon, 4 Sept 2023 at 17:49, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> > > >
> > > > On Mon, 4 Sept 2023 at 17:47, Hans-Peter Nilsson via Libstdc++
> > > > <libstdc++@gcc.gnu.org> wrote:
> > > > >
> > > > > > Date: Fri, 1 Sep 2023 12:16:40 +0100
> > > > > > Reply-To: Jonathan Wakely <jwakely@redhat.com>
> > > > > >
> > > > > > On Wed, 23 Aug 2023 at 17:03, Jonathan Wakely via Libstdc++
> > > > > > <libstdc++@gcc.gnu.org> wrote:
> > > > > > >
> > > > > > > Any objections to this? It's a C++23 feture, so should be enabled by
> > > > > > > default.
> > > > > >
> > > > > > I've pushed this to trunk, so let's see what breaks!
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > -- >8 --
> > > > > > >
> > > > > > > This causes libstdc++_libbacktrace.a to be built by default. This might
> > > > > > > fail on some targets, in which case we can make the 'auto' choice expand
> > > > > > > to either 'yes' or 'no' depending on the target.
> > > > > > >
> > > > > > > libstdc++-v3/ChangeLog:
> > > > > > >
> > > > > > >         * acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Default to yes.
> > > > > > >         * configure: Regenerate.
> > > > >
> > > > > Incidentally, should check_effective_target_stacktrace in
> > > > > libstdc++.exp also be adjusted to match; removing the
> > > > > _GLIBCXX_HOSTED condition?
> > > >
> > > > No, it should still depend on is_hosted. The acinclude.m4 macro should
> > > > check that.
> > >
> > > Done in r14-3761-g6de5f5a4fe85bd
> >
> > Aha, that's what you meant.  I thought you meant that just
> > check_effective_target_stacktrace should be gated on
> > $is_hosted.
> >
> > Yeah, it makes sense not to have backtrace enabled by
> > default for ! $is_hosted.  On the other hand, bare-iron
> > targets like cris-elf apparently *are* hosted, according to
> > "#if __STDC_HOSTED__".  I guess I'll have to dig into what
> > the definition of "hosted" is, because I don't agree by the
> > layman obvious definition.  Maybe there's a bug to fix.
>
> I don't think there's a bug. $is_hosted is true for
> --enable-hosted-libstdcxx which is on by default.

And IIRC __STDC_HOSTED__ is defined unless you compile with -ffreestanding.


>
> > There sure are many yaks to shave these days.
> >
> > brgds, H-P
> >
Hans-Peter Nilsson Sept. 6, 2023, 11:51 p.m. UTC | #10
> Date: Thu, 7 Sep 2023 00:11:04 +0100
> From: Jonathan Wakely via Gcc-patches <gcc-patches@gcc.gnu.org>

> On Thu, 7 Sept 2023 at 00:10, Jonathan Wakely <jwakely@redhat.com> wrote:
> > I don't think there's a bug. $is_hosted is true for
> > --enable-hosted-libstdcxx which is on by default.
> 
> And IIRC __STDC_HOSTED__ is defined unless you compile with -ffreestanding.

Also documented and thus fine by any (reasonable)
definition :) no need for anyone (me) to guess.

brgds, H-P
diff mbox series

Patch

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index b25378eaace..50c808c6b2d 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -5481,7 +5481,7 @@  BACKTRACE_CPPFLAGS="$BACKTRACE_CPPFLAGS -DBACKTRACE_ELF_SIZE=$elfsize"
 
   AC_MSG_CHECKING([whether to build libbacktrace support])
   if test "$enable_libstdcxx_backtrace" = "auto"; then
-    enable_libstdcxx_backtrace=no
+    enable_libstdcxx_backtrace=yes
   fi
   AC_MSG_RESULT($enable_libstdcxx_backtrace)
   if test "$enable_libstdcxx_backtrace" = "yes"; then