public inbox for libstdc++@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely@redhat.com>
To: "François Dumont" <frs.dumont@gmail.com>
Cc: "libstdc++@gcc.gnu.org" <libstdc++@gcc.gnu.org>,
	gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Fix version namespace build
Date: Thu, 11 Feb 2021 17:29:22 +0000	[thread overview]
Message-ID: <20210211172922.GE3008@redhat.com> (raw)
In-Reply-To: <YCVL4a6TKgtQMZrB@redhat.com>

On 11/02/21 15:23 +0000, Jonathan Wakely wrote:
>On 09/02/21 22:05 +0100, François Dumont via Libstdc++ wrote:
>>    libstdc++: Fix versioned namespace build
>>
>>    libstdc++-v3/ChangeLog:
>>
>>            * libsupc++/eh_ptr.cc (exception_ptr(__safe_bool)): Define if
>>            _GLIBCXX_EH_PTR_COMPAT is defined.
>>            (exception_ptr::_M_safe_bool_dummy()): Likewise.
>>            (exception_ptr::operator!()): Likewise.
>>            (exception_ptr::opeerator __safe_bool()): Likewise.
>>
>>Ok to commit ?
>
>No, this is not correct. Those functions are declared in the
>header if included from C++98 code:
>
>#if (__cplusplus < 201103L) || defined (_GLIBCXX_EH_PTR_COMPAT)
>      typedef void (exception_ptr::*__safe_bool)();
>
>      // For construction from nullptr or 0.
>      exception_ptr(__safe_bool) _GLIBCXX_USE_NOEXCEPT;
>#endif
>
>With your change, C++98 code that calls those functions will be unable
>to link to libstdc++.so.8 because the functions won't be defined in
>the library.
>
>The simplest fix would be to revert this change:
>
>--- a/libstdc++-v3/libsupc++/eh_ptr.cc
>+++ b/libstdc++-v3/libsupc++/eh_ptr.cc
>@@ -25,7 +25,12 @@
> #include <bits/c++config.h>
> #include "eh_atomics.h"
>
>+#if ! _GLIBCXX_INLINE_VERSION
>+// This macro causes exception_ptr to declare an older API (with corresponding
>+// definitions in this file) and to mark some inline functions as "used" so
>+// that definitions will be emitted in this translation unit.
> #define _GLIBCXX_EH_PTR_COMPAT
>+#endif
>
> #include <exception>
> #include <bits/exception_ptr.h>
>
>But that leaves the unwanted operator== definitions in libstdc++.so.8
>so the attached patch (only tested with unversioned namespace) is
>probably what we want to do. Does it fix the problem?

I've now tested the patch below and committed it.


>diff --git a/libstdc++-v3/libsupc++/eh_ptr.cc b/libstdc++-v3/libsupc++/eh_ptr.cc
>index 5d8ac1d879a..5c4685606fe 100644
>--- a/libstdc++-v3/libsupc++/eh_ptr.cc
>+++ b/libstdc++-v3/libsupc++/eh_ptr.cc
>@@ -25,11 +25,15 @@
> #include <bits/c++config.h>
> #include "eh_atomics.h"
> 
>-#if ! _GLIBCXX_INLINE_VERSION
> // This macro causes exception_ptr to declare an older API (with corresponding
>-// definitions in this file) and to mark some inline functions as "used" so
>-// that definitions will be emitted in this translation unit.
>+// definitions in this file).
> #define _GLIBCXX_EH_PTR_COMPAT
>+
>+#if ! _GLIBCXX_INLINE_VERSION
>+// This macro causes some inline functions in exception_ptr to be marked
>+// as "used" so that definitions will be emitted in this translation unit.
>+// We need this because those functions were not inline in previous releases.
>+#define _GLIBCXX_EH_PTR_RELOPS_COMPAT
> #endif
> 
> #include <exception>
>diff --git a/libstdc++-v3/libsupc++/exception_ptr.h b/libstdc++-v3/libsupc++/exception_ptr.h
>index 6d41b34fabe..9943668d9b3 100644
>--- a/libstdc++-v3/libsupc++/exception_ptr.h
>+++ b/libstdc++-v3/libsupc++/exception_ptr.h
>@@ -39,7 +39,7 @@
> #include <typeinfo>
> #include <new>
> 
>-#ifdef _GLIBCXX_EH_PTR_COMPAT
>+#ifdef _GLIBCXX_EH_PTR_RELOPS_COMPAT
> # define _GLIBCXX_EH_PTR_USED __attribute__((__used__))
> #else
> # define _GLIBCXX_EH_PTR_USED
>@@ -153,7 +153,7 @@ namespace std
> #endif
> 
> #if __cpp_impl_three_way_comparison >= 201907L \
>-      && ! defined _GLIBCXX_EH_PTR_COMPAT
>+      && ! defined _GLIBCXX_EH_PTR_RELOPS_COMPAT
>       friend bool
>       operator==(const exception_ptr&, const exception_ptr&) noexcept = default;
> #else


      reply	other threads:[~2021-02-11 17:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-09 21:05 François Dumont
2021-02-11 15:23 ` Jonathan Wakely
2021-02-11 17:29   ` Jonathan Wakely [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210211172922.GE3008@redhat.com \
    --to=jwakely@redhat.com \
    --cc=frs.dumont@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=libstdc++@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).