[llvm-bugs] [Bug 48634] New: std::atomic<long double>::compare_exchange_weak does not update `expected` on failure

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Dec 30 03:54:42 PST 2020


https://bugs.llvm.org/show_bug.cgi?id=48634

            Bug ID: 48634
           Summary: std::atomic<long double>::compare_exchange_weak does
                    not update `expected` on failure
           Product: clang
           Version: 11.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++2a
          Assignee: unassignedclangbugs at nondot.org
          Reporter: max at arangodb.com
                CC: blitzrakete at gmail.com, erik.pilkington at gmail.com,
                    llvm-bugs at lists.llvm.org, richard-llvm at metafoo.co.uk

Created attachment 24327
  --> https://bugs.llvm.org/attachment.cgi?id=24327&action=edit
Program reproducing the bug.

This program does not behave as intended:

#include <atomic>
#include <iostream>
int main() {
  std::atomic<long double> x;
  x.store(1.0);
  long double tmp = 2.0;
  bool worked = x.compare_exchange_weak(tmp, 3.0);
  std::cout << "worked " << worked << " set tmp to " << tmp << std::endl;

  std::atomic<double> x2;
  x2.store(1.0);
  double tmp2 = 2.0;
  worked = x2.compare_exchange_weak(tmp2, 3.0);
  std::cout << "worked " << worked << " set tmp to " << tmp2 << std::endl;

  return 0;
}

I compile with

  clang++-12 -std=c++17 atomiclongdoublecompareexchangeweak.cpp \
             -o atomiclongdoublecompareexchangeweak -Wall -O0 -g -latomic

The output is:

worked 0 set tmp to 2
worked 0 set tmp to 1

The expected output is

worked 0 set tmp to 1
worked 0 set tmp to 1

My version of clang++-12 is:

% clang++-12 -v
Ubuntu clang version
12.0.0-++20201229052625+b76014a4f15a-1~exp1~20201229163322.268
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/10
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/10
Candidate multilib: .;@m64
Selected multilib: .;@m64

The same problem occurs with clang++11 and other optimization levels.

The problem is that

  std::atomic<long double>::compare_exchange_weak(long double& expected,
                                                  long double desired)

does not update `expected` as specified when the expected value is not
found.

Here are the libraries my program is linked against:

% ldd ./atomiclongdoublecompareexchangeweak
        linux-vdso.so.1 (0x00007fffe5b79000)
        libatomic.so.1 => /lib/x86_64-linux-gnu/libatomic.so.1
(0x00007f61dcb69000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6
(0x00007f61dc988000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f61dc839000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x00007f61dc81e000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f61dc62c000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f61dc609000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f61dcb9c000)

The problem seems to be that the atomic headers lead to the fact that in
the end the compiler intrinsic

  __atomic_compare_exchange

is called for the 16 byte case. Unfortunately, I cannot easily find the
source code for this. In any case this function seems to misbehave
for the 16 byte case. I have traced the assembler code and this shows
the wrong behaviour.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20201230/e6cd9e43/attachment.html>


More information about the llvm-bugs mailing list