From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 437963858C50; Fri, 26 Apr 2024 15:50:29 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 437963858C50
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1714146629;
	bh=oW1ChoZzy1R7mNqhdSWooL6r/nA3SImZvuiX4dVvaso=;
	h=From:To:Subject:Date:From;
	b=WkBH2QQT6TrEQGa9Zl2x6c0f2eOBQJUP8pbgi+ppBhkUZVkMxD+7nm2u61PTbXURw
	 L5GJMug9VELhvBBM4MDBuzvzljiBbm2iCL3HPufoTVqsb4JfTsoxD75vIjDWPklIk3
	 rZlpJfOqDd5cr53KqWyALmBEUdJVqNv4TpzcXS4A=
From: "pdimov at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/114865] New: std::atomic<X>::compare_exchange_strong
 seems to hang under GCC 13 on Ubuntu 23.04
Date: Fri, 26 Apr 2024 15:50:28 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 13.2.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pdimov at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status
 bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-114865-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

            Bug ID: 114865
           Summary: std::atomic<X>::compare_exchange_strong seems to hang
                    under GCC 13 on Ubuntu 23.04
           Product: gcc
           Version: 13.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pdimov at gmail dot com
  Target Milestone: ---

I'm getting weird hangs on Github Actions when using
`std::atomic<state_type>::compare_exchange_strong` under GCC 13 on Ubuntu 2=
3.04
(only; GCC 12 and earlier on Ubuntu 22.04 and earlier work). `state_type` is
defined as

```
struct state_type
{
    std::uint64_t timestamp;
    std::uint16_t clock_seq;
};
```

and the code doing the CAS is

```
auto oldst =3D ps_->load( std::memory_order_relaxed );

for( ;; )
{
    auto newst =3D get_new_state( oldst );

    if( ps_->compare_exchange_strong( oldst, newst, std::memory_order_relax=
ed,
std::memory_order_relaxed ) )
    {
        state_ =3D newst;
        break;
    }
}
```

where `ps` is of type `std::atomic<state_type>*`.

At a glance, I see nothing immediately wrong with the generated code
(https://godbolt.org/z/8Ee3hrTz8).

However, when I change `state_type` to

```
struct state_type
{
    std::uint64_t timestamp;
    std::uint16_t clock_seq;
    std::uint16_t padding[ 3 ];
};
```
the hangs disappear. This leads me to think that the problem is caused by t=
he
original struct having padding, which isn't being handled correctly for some
reason.

As we know, `std::atomic<T>::compare_exchange_strong` is carefully specifie=
d to
take and return `expected` by reference, such that it can both compare the
entire object as if via `memcmp` (including the padding), and return it as =
if
by `memcpy`, again including the padding. Even though the padding bits of t=
he
initial value returned by the atomic load are unspecified, at most one
iteration of the loop would be required for the padding bits to converge and
for the CAS to succeed.

However, going by the symptoms alone, this doesn't seem to be the case here.

The problem may well be inside libatomic, of course; I have no way to tell.

One GHA run showing the issue is
https://github.com/boostorg/uuid/actions/runs/8821753835, where only the GC=
C 13
job times out.=