public inbox for libstdc++@gcc.gnu.org
 help / color / mirror / Atom feed
From: Thiago Macieira <thiago.macieira@intel.com>
To: Ville Voutilainen <ville.voutilainen@gmail.com>,
	Jonathan Wakely <jwakely@redhat.com>
Cc: Thomas Rodgers <trodgers@redhat.com>, libstdc++ <libstdc++@gcc.gnu.org>
Subject: Re: C++2a synchronisation inefficient in GCC 11
Date: Wed, 3 Mar 2021 09:07:51 -0800	[thread overview]
Message-ID: <5422241.zR2LmqfNYo@tjmaciei-mobl1> (raw)
In-Reply-To: <20210303143020.GR3008@redhat.com>

On Wednesday, 3 March 2021 06:30:20 PST Jonathan Wakely wrote:
> Yes, exactly. They could still do that if some additional option/macro
> was needed to get to those new facilities though.
> 
> My concern is that if we add a new "I know what I'm doing" option,
> everybody defines it (because that's what blog posts and youtube
> videos and conference talks tell them to do, because that gives them
> the new shiny things) and then it just becomes a default.
> 
> Maybe Qt wouldn't define it, but plenty would.

Well, if you define the "void warranty" option and you break things, you get 
to keep both pieces.

Another option is to fiddle with the include path. 

$ gcc -v -E -xc++ /dev/null
Using built-in specs.
[...]
#include <...> search starts here:
 /usr/lib64/gcc/x86_64-generic-linux/10/../../../../include/c++/10
 /usr/lib64/gcc/x86_64-generic-linux/10/../../../../include/c++/10/x86_64-
generic-linux
 /usr/lib64/gcc/x86_64-generic-linux/10/../../../../include/c++/10/backward
 /usr/lib64/gcc/x86_64-generic-linux/10/include
 /usr/local/include
 /usr/lib64/gcc/x86_64-generic-linux/10/include-fixed
 /usr/include

That "backward" has always got me thinking. What if we had a command-line 
option like -fexperimental-c++ option that added the $CXXROOT/experimental 
(complete with its bits/ and $ARCH subdirs)? That way, the regular 
atomic_base.h could do:

#if __cplusplus > 201703L && __has_include(<bits/atomic_wait.h>)

And the second conditional would fail unless the option is provided.

The advantage of a compiler option is that you need each DSO to consciously 
add something to their build systems and that can't be done by header-only 
libraries. That's like MSVC's /std:c++latest, which is documented by MS as 
"here there be dragons".

GCC can also generate some extra bit of assembly to mark the final executable 
as using experimental API, so distributors can easily tell that unfinished API 
was used. I've successfully done this for Qt using ELF versions.

$ rpm -qR kwin5 | grep PRIVATE
libQt5Core.so.5(Qt_5.15.2_PRIVATE_API)(64bit)
libQt5Gui.so.5(Qt_5.15.2_PRIVATE_API)(64bit)

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering




  reply	other threads:[~2021-03-03 17:07 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-25 22:50 Thiago Macieira
2021-02-26 11:19 ` Jonathan Wakely
2021-02-26 17:37   ` Thiago Macieira
2021-02-26 18:29     ` Jonathan Wakely
2021-02-26 19:30       ` Ville Voutilainen
2021-02-26 21:17         ` Jonathan Wakely
2021-02-26 21:18           ` Ville Voutilainen
2021-02-26 21:39             ` Jonathan Wakely
2021-02-26 18:47     ` Ville Voutilainen
2021-02-26 23:53       ` Thiago Macieira
2021-02-26 23:58         ` Ville Voutilainen
2021-02-27  0:11           ` Thiago Macieira
2021-02-27  0:18             ` Ville Voutilainen
2021-02-27  0:36               ` Thiago Macieira
2021-02-27  0:44                 ` Ville Voutilainen
2021-02-27  0:53                   ` Thiago Macieira
2021-02-27  1:03                     ` Ville Voutilainen
2021-03-03 14:30                   ` Jonathan Wakely
2021-03-03 17:07                     ` Thiago Macieira [this message]
2021-03-03 17:14                       ` Jonathan Wakely
2021-02-27  0:22             ` Marc Glisse
2021-02-27  0:30               ` Ville Voutilainen
2021-02-27  0:43               ` Thiago Macieira
2021-03-03 14:24         ` Jonathan Wakely
2021-03-03 17:12           ` Thiago Macieira
2021-02-26 15:59 ` [PATCH 1/5] std::latch: reduce internal implementation from ptrdiff_t to int Thiago Macieira
2021-02-26 15:59   ` [PATCH 2/5] Atomic __platform_wait: accept any 32-bit type, not just int Thiago Macieira
2021-03-03 14:34     ` Jonathan Wakely
2021-03-03 16:21       ` Jonathan Wakely
2021-03-03 17:27         ` Thiago Macieira
2021-03-03 17:34         ` Ville Voutilainen
2021-03-03 17:41           ` Jonathan Wakely
2021-02-26 15:59   ` [PATCH 3/5] std::__atomic_wait: don't use __detail::__waiter with futex Thiago Macieira
2021-02-26 15:59   ` [PATCH 4/5] barrier: use int instead of unsigned char for the phase state Thiago Macieira
2021-02-28 15:05     ` Hans-Peter Nilsson
2021-03-01 16:28       ` Thomas Rodgers
2021-03-01 17:24       ` Thiago Macieira
2021-03-01 17:38         ` Thomas Rodgers
2021-03-01 17:40           ` Thomas Rodgers
2021-03-01 18:06           ` Thiago Macieira
2021-03-01 19:08             ` Thomas Rodgers
2021-03-01 18:12         ` Ville Voutilainen
2021-03-01 19:44           ` Thiago Macieira
2021-03-01 20:35             ` Ville Voutilainen
2021-03-01 21:54               ` Thiago Macieira
2021-03-01 22:04                 ` Ville Voutilainen
2021-03-01 22:21                   ` Thiago Macieira
2021-03-01 22:31                     ` Ville Voutilainen
2021-03-01 22:40                       ` Thiago Macieira
2021-02-26 15:59   ` [PATCH 5/5] barrier: optimise by not having the hasher in a loop Thiago Macieira
2021-03-03 14:36     ` Jonathan Wakely
2021-02-26 18:14   ` [PATCH 1/5] std::latch: reduce internal implementation from ptrdiff_t to int Andreas Schwab
2021-02-26 19:08     ` Thiago Macieira
2021-02-26 19:31       ` Andreas Schwab
2021-02-27  0:13         ` Thiago Macieira
2021-02-28 21:31           ` Hans-Peter Nilsson
2021-03-01  8:56             ` Richard Biener
2021-03-03 14:56               ` Jonathan Wakely
2021-03-03 15:02                 ` Andreas Schwab
2021-03-03 15:10                 ` Jonathan Wakely
2021-03-03 15:37                 ` Hans-Peter Nilsson
2021-03-01 16:32             ` Thomas Rodgers
2021-03-03 14:34   ` Jonathan Wakely
2021-03-03 17:14     ` Thiago Macieira
2021-03-03 17:18       ` Jonathan Wakely
2021-02-27  1:13 ` C++2a synchronisation inefficient in GCC 11 Thomas Rodgers
2021-02-27  1:29   ` Thomas Rodgers
2021-02-27  3:01     ` Thomas Rodgers
2021-03-01 17:46       ` Thomas Rodgers
2021-03-01 18:00         ` Thiago Macieira
2021-03-01 18:34           ` Thomas Rodgers
2021-03-01 19:11             ` Thiago Macieira
2021-02-27  2:02   ` Ville Voutilainen

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=5422241.zR2LmqfNYo@tjmaciei-mobl1 \
    --to=thiago.macieira@intel.com \
    --cc=jwakely@redhat.com \
    --cc=libstdc++@gcc.gnu.org \
    --cc=trodgers@redhat.com \
    --cc=ville.voutilainen@gmail.com \
    /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).