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>
Cc: libstdc++ <libstdc++@gcc.gnu.org>,
	gcc-patches List <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH 4/5] barrier: use int instead of unsigned char for the phase state
Date: Mon, 1 Mar 2021 13:54:04 -0800	[thread overview]
Message-ID: <3732429.s6FRLjrGHh@tjmaciei-mobl1> (raw)
In-Reply-To: <CAFk2RUYFv1FmpAgstX3AiJjJcJC3GYVcCNALbK-Zcs4n_Xr7oA@mail.gmail.com>

On Monday, 1 March 2021 12:35:05 PST Ville Voutilainen wrote:
> I can't make the above code work, in any reasonable manner, because
> it's doing feature detection incorrectly. :)
> What I can imagine doing, however, is this:
> 
> 1) a published IS always bumps feature-macro values (this won't help
> now, it's a future fix, we don't currently do this in WG21)

This is mostly already the case. I haven't seen any need to bump the values.

> 2) an implementation uses the pre-IS draft values before it deems itself
> stable 

Before the IS is stable? From what I've seen so far, the macros are always 
around the month of the latest draft of a given feature. So if an 
implementation implemented an earlier draft, the macro version would increase 
in a new draft coming before the IS.

I think we just need to be careful of updates done after the latest draft is 
adopted, usually by NBs. Those have to bump the macro too. I think you're in 
good speaking terms with the Finland NB :-)

> 3) users who want stability should require the feature-testing macro
> to have at least the IS value

True. That's not the stability I was talking about, but it could be done.

> 4) adventurous users can either use the macro without checking its
> value, or use at least the value that gives them
> whatever shiny toy they're interested in

Fair enough.

Please note I am not talking about the stability of the feature as described 
in the standard or a proposal or draft. I am talking about the stability of 
the implementation. C++20 is out and the atomic-wait feature is stable, as 
defined by the standard. What isn't stable is GCC's implementation of it.

But your suggestion does work. We don't need to apply them to all macros, only 
those that are new in a given version, like __cpp_lib_atomic_wait or 
__cpp_lib_latch in this case. Alternatively, implementations can set the macro 
to a given value below the standard-required one (incl. 1) to indicate that 
they haven't achieved stability.

That would make my check:

#if __cplusplus >= 202002L && __has_include(<latch>)
#  include <latch>
#endif
#if __cpp_lib_latch < 201907L
#  error "Please upgrade your Standard Library"
#endif

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




  reply	other threads:[~2021-03-01 21:54 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-25 22:50 C++2a synchronisation inefficient in GCC 11 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
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 [this message]
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=3732429.s6FRLjrGHh@tjmaciei-mobl1 \
    --to=thiago.macieira@intel.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=libstdc++@gcc.gnu.org \
    --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).