public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/102177] New: Implement C++17 P0418R2
@ 2021-09-02 14:28 jakub at gcc dot gnu.org
  2021-09-02 14:28 ` [Bug c++/102177] " jakub at gcc dot gnu.org
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-09-02 14:28 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102177

            Bug ID: 102177
           Summary: Implement C++17 P0418R2
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

I think we aren't implementing https://wg21.link/p0418r2
which dropped the requirement that failure mode can't be stronger than success
mode.
For
long
bar (long *x, long y, long z)
{
  __atomic_compare_exchange_n (x, &y, z, 0, __ATOMIC_RELAXED,
__ATOMIC_SEQ_CST);
  return y;
}
we warn:
warning: failure memory model cannot be stronger than success memory model for
‘__atomic_compare_exchange’ [-Winvalid-memory-model]
and document it in doc/extend.texi:
Otherwise, @code{false} is returned and memory is affected according
to @var{failure_memorder}. This memory order cannot be
@code{__ATOMIC_RELEASE} nor @code{__ATOMIC_ACQ_REL}.  It also cannot be a
stronger order than that specified by @var{success_memorder}.
and libstdc++ has:
        __glibcxx_assert(__b2 <= __b1);
in various spots in bits/atomic_base.h.

Do we emit right code on aarch64 and other weak ordering targets for this case
despite the warning?

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug c++/102177] Implement C++17 P0418R2
  2021-09-02 14:28 [Bug c++/102177] New: Implement C++17 P0418R2 jakub at gcc dot gnu.org
@ 2021-09-02 14:28 ` jakub at gcc dot gnu.org
  2021-09-02 14:40 ` jakub at gcc dot gnu.org
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-09-02 14:28 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102177

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-09-02
     Ever confirmed|0                           |1
                 CC|                            |amacleod at redhat dot com,
                   |                            |redi at gcc dot gnu.org,
                   |                            |rsandifo at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug c++/102177] Implement C++17 P0418R2
  2021-09-02 14:28 [Bug c++/102177] New: Implement C++17 P0418R2 jakub at gcc dot gnu.org
  2021-09-02 14:28 ` [Bug c++/102177] " jakub at gcc dot gnu.org
@ 2021-09-02 14:40 ` jakub at gcc dot gnu.org
  2021-09-02 15:14 ` jakub at gcc dot gnu.org
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-09-02 14:40 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102177

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dje at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
E.g. aarch64 has comment like:
  /* Normally the succ memory model must be stronger than fail, but in the
     unlikely event of fail being ACQUIRE and succ being RELEASE we need to
     promote succ to ACQ_REL so that we don't lose the acquire semantics.  */
which makes me think that maybe it needs some work when the stronger
requirement isn't honored.

What about powerpc?

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug c++/102177] Implement C++17 P0418R2
  2021-09-02 14:28 [Bug c++/102177] New: Implement C++17 P0418R2 jakub at gcc dot gnu.org
  2021-09-02 14:28 ` [Bug c++/102177] " jakub at gcc dot gnu.org
  2021-09-02 14:40 ` jakub at gcc dot gnu.org
@ 2021-09-02 15:14 ` jakub at gcc dot gnu.org
  2021-09-02 17:51 ` cvs-commit at gcc dot gnu.org
  2022-04-21 15:33 ` cvs-commit at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-09-02 15:14 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102177

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 51406
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51406&action=edit
gcc12-pr102177.patch

Untested patch to remove the warning and just use maximum for success if weaker
than failure instead of always seq_cst.

On the other side, even current C2X draft has that:
The failure argument shall be no stronger than the success argument.
requirement.  So should we keep the restriction for __atomic_* APIs and just
pass maximum from libstdc++ headers?

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug c++/102177] Implement C++17 P0418R2
  2021-09-02 14:28 [Bug c++/102177] New: Implement C++17 P0418R2 jakub at gcc dot gnu.org
                   ` (2 preceding siblings ...)
  2021-09-02 15:14 ` jakub at gcc dot gnu.org
@ 2021-09-02 17:51 ` cvs-commit at gcc dot gnu.org
  2022-04-21 15:33 ` cvs-commit at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-09-02 17:51 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102177

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:dba1ab212292839572fda60df00965e094a11252

commit r12-3317-gdba1ab212292839572fda60df00965e094a11252
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu Sep 2 15:29:22 2021 +0100

    libstdc++: Remove "no stronger" assertion in compare exchange [PR102177]

    P0418R2 removed some preconditions from std::atomic::compare_exchange_*
    but we still enforce them via __glibcxx_assert. This removes those
    assertions.

    Signed-off-by: Jonathan Wakely <jwakely@redhat.com>

    libstdc++-v3/ChangeLog:

            PR c++/102177
            * include/bits/atomic_base.h (__is_valid_cmpexch_failure_order):
            New function to check if a memory order is valid for the failure
            case of compare exchange operations.
            (__atomic_base<I>::compare_exchange_weak): Simplify assertions
            by using __is_valid_cmpexch_failure_order.
            (__atomic_base<I>::compare_exchange_strong): Likewise.
            (__atomic_base<P*>::compare_exchange_weak): Likewise.
            (__atomic_base<P*>::compare_exchange_strong): Likewise.
            (__atomic_impl::compare_exchange_weak): Add assertion.
            (__atomic_impl::compare_exchange_strong): Likewise.
            * include/std/atomic (atomic::compare_exchange_weak): Likewise.
            (atomic::compare_exchange_strong): Likewise.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug c++/102177] Implement C++17 P0418R2
  2021-09-02 14:28 [Bug c++/102177] New: Implement C++17 P0418R2 jakub at gcc dot gnu.org
                   ` (3 preceding siblings ...)
  2021-09-02 17:51 ` cvs-commit at gcc dot gnu.org
@ 2022-04-21 15:33 ` cvs-commit at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-04-21 15:33 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102177

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:fef3d31bd35f53cbcacaec63b279d38c38b78abe

commit r11-9926-gfef3d31bd35f53cbcacaec63b279d38c38b78abe
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu Sep 2 15:29:22 2021 +0100

    libstdc++: Remove "no stronger" assertion in compare exchange [PR102177]

    P0418R2 removed some preconditions from std::atomic::compare_exchange_*
    but we still enforce them via __glibcxx_assert. This removes those
    assertions.

    Signed-off-by: Jonathan Wakely <jwakely@redhat.com>

    libstdc++-v3/ChangeLog:

            PR c++/102177
            * include/bits/atomic_base.h (__is_valid_cmpexch_failure_order):
            New function to check if a memory order is valid for the failure
            case of compare exchange operations.
            (__atomic_base<I>::compare_exchange_weak): Simplify assertions
            by using __is_valid_cmpexch_failure_order.
            (__atomic_base<I>::compare_exchange_strong): Likewise.
            (__atomic_base<P*>::compare_exchange_weak): Likewise.
            (__atomic_base<P*>::compare_exchange_strong): Likewise.
            (__atomic_impl::compare_exchange_weak): Add assertion.
            (__atomic_impl::compare_exchange_strong): Likewise.
            * include/std/atomic (atomic::compare_exchange_weak): Likewise.
            (atomic::compare_exchange_strong): Likewise.

    (cherry picked from commit dba1ab212292839572fda60df00965e094a11252)

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2022-04-21 15:33 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-02 14:28 [Bug c++/102177] New: Implement C++17 P0418R2 jakub at gcc dot gnu.org
2021-09-02 14:28 ` [Bug c++/102177] " jakub at gcc dot gnu.org
2021-09-02 14:40 ` jakub at gcc dot gnu.org
2021-09-02 15:14 ` jakub at gcc dot gnu.org
2021-09-02 17:51 ` cvs-commit at gcc dot gnu.org
2022-04-21 15:33 ` cvs-commit at gcc dot gnu.org

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).