ivmai / libatomic_ops

The atomic_ops project (Atomic memory update operations portable implementation)

The atomic_ops library (libatomic_ops)

IN NEW CODE, PLEASE USE C11 OR C++14 STANDARD ATOMICS INSTEAD OF THE CORE LIBRARY IN THIS PACKAGE.

This is version 7.9.0 (next release development) of libatomic_ops.

License: MIT for core library / GPL-2.0 for gpl extension.

Download

You might find a more recent/stable version on the Download page, or BDWGC site.

Also, the latest bug fixes and new features are available in the development repository.

Overview

This package provides semi-portable access to hardware-provided atomic memory update operations on a number of architectures. These might allow you to write code:

• That does more interesting things in signal handlers.

• Makes more effective use of multiprocessors by allowing you to write clever lock-free code. Note that such code is very difficult to get right, and will unavoidably be less portable than lock-based code. It is also not always faster than lock-based code. But it may occasionally be a large performance win.

• To experiment with new and much better thread programming paradigms, etc.

Please see other README files for the details:

• README_details.txt - details about atomic_ops.h

• README_malloc.txt - a simple almost-lock-free malloc implementation (part of libatomic_ops_gpl)

• README_stack.txt - an almost lock-free LIFO linked lists (stack) implementation (part of libatomic_ops_gpl)

Installation and Usage

The configuration and build scripts for this package were generated by Automake/Autoconf. ./configure; make; sudo make install in this directory should work. For a more customized build, see the output of ./configure --help. To build it from the development repository, ./autogen.sh should be executed first.

Alternatively, CMake could be use to build this package, e.g. cmake . && cmake --build . in this directory should work.

Note that much of the content of this library is in the header files. However, two small libraries are built and installed:

• libatomic_ops.a is a support (core) library, which is not needed on some platforms. This is intended to be usable, under some mild restrictions, in free or proprietary code, as are all the header files. See LICENSE for more details about the licensing.

• libatomic_ops_gpl.a is a so called gpl extension library containing some higher level facilities. This code is covered by the GPL. The contents correspond to the headers atomic_ops_malloc.h and atomic_ops_stack.h. Not built and not installed if --disable-gpl option is passed to configure (or if -Denable_gpl=OFF option is passed to cmake if the latter is used to build the package). The licensing details are given in COPYING and LICENSE files.

Platform Specific Notes

Win32/64: src/Makefile.msft contains a very simple Makefile for building and running tests and building the gpl library. The core libatomic_ops implementation is entirely in header files (libatomic_ops.lib is built anyway to match that of the configure-based build process, but libatomic_ops.lib has only the implementation of the internal AO_pause() used by the gpl library). More information is provided in README_win32.txt file.

HP-UX/PA-RISC: aCC -Ae won't work as a C compiler, since it doesn't support inline assembly code. Use cc.

Feedback, Contribution, Questions and Notifications

Please address bug reports and new feature ideas to GitHub issues. Before the submission please check that it has not been done yet by someone else.

If you want to contribute, submit a pull request to GitHub.

If you need help, use Stack Overflow. Older questions on the site can be found by this query. Older technical discussions are also available in bdwgc mailing list archive - it can be downloaded as a compressed file or browsed at Narkive (please search for atomic keyword).

To get new release announcements, subscribe to RSS feed. (To receive the notifications by email, a 3rd-party free service like IFTTT RSS Feed can be setup.) To be notified on all issues, please watch the project on GitHub.

Copyright & Warranty, Contributors

Please be aware of the dual nature of the license of libatomic_ops:

• the core part (implementing semi-portable access to hardware-provided atomic memory operations) is released under MIT license

• the gpl extension (almost lock-free malloc and stack implementations) and the tests are released under GPL-2.0 license

The exact licensing information is provided in LICENSE file.

The library contributors are listed in AUTHORS file.

libatomic_ops's Issues

Outdated config.guess Files

When I was building the package for the riscv64 platform, the ./configure step reported ./config.guess: unable to guess system type. When I updated the relevant files with autoreconf -fi, the build was successful. So config.guess and config.sub in this project need to be updated to work with more architectures.

atomic_ops_stack.c:142: undefined reference to `AO_pause'

hello,

I encountered a link error to AO_pause in libatomic_ops_gpl on mingw-w64 for x86_64 target (i686 is fine):

libtool: link: x86_64-w64-mingw32-gcc -shared  .libs/atomic_ops_stack.o .libs/atomic_ops_malloc.o    -O2 -g   -o .libs/libatomic_ops_gpl-1.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libatomic_ops_gpl.dll.a
.libs/atomic_ops_stack.o: In function `AO_stack_pop_explicit_aux_acquire':
/home/xantares/projects/aur-scripts/mingw-w64-libatomic_ops/src/libatomic_ops-libatomic_ops-7_4_2/build-x86_64-w64-mingw32/src/../../src/atomic_ops_stack.c:142: undefined reference to `AO_pause'
collect2: error: ld returned 1 exit status
Makefile:547: recipe for target 'libatomic_ops_gpl.la' failed

If I add atomic_ops.c where AO_pause is defined to the list of sources fils of libatomic_ops_gpl it goes fine:

libatomic_ops_gpl_la_SOURCES = atomic_ops.c atomic_ops_stack.c atomic_ops_malloc.c

here's the full log:

configure: WARNING: you should use --build, --host, --target
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-w64-mingw32
checking target system type... x86_64-w64-mingw32
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for x86_64-w64-mingw32-strip... x86_64-w64-mingw32-strip
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for style of include used by make... GNU
checking for x86_64-w64-mingw32-gcc... x86_64-w64-mingw32-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether x86_64-w64-mingw32-gcc accepts -g... yes
checking for x86_64-w64-mingw32-gcc option to accept ISO C89... none needed
checking whether x86_64-w64-mingw32-gcc understands -c and -o together... yes
checking dependency style of x86_64-w64-mingw32-gcc... gcc3
checking dependency style of x86_64-w64-mingw32-gcc... gcc3
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by x86_64-w64-mingw32-gcc... /usr/x86_64-w64-mingw32/bin/ld
checking if the linker (/usr/x86_64-w64-mingw32/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/x86_64-w64-mingw32-nm -B
checking the name lister (/usr/bin/x86_64-w64-mingw32-nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-unknown-linux-gnu file names to x86_64-w64-mingw32 format... func_convert_file_nix_to_w32
checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/x86_64-w64-mingw32/bin/ld option to reload object files... -r
checking for x86_64-w64-mingw32-objdump... x86_64-w64-mingw32-objdump
checking how to recognize dependent libraries... file_magic ^x86 archive import|^x86 DLL
checking for x86_64-w64-mingw32-dlltool... x86_64-w64-mingw32-dlltool
checking how to associate runtime and link libraries... func_cygming_dll_for_implib
checking for x86_64-w64-mingw32-ar... x86_64-w64-mingw32-ar
checking for archiver @FILE support... @
checking for x86_64-w64-mingw32-strip... (cached) x86_64-w64-mingw32-strip
checking for x86_64-w64-mingw32-ranlib... x86_64-w64-mingw32-ranlib
checking command to parse /usr/bin/x86_64-w64-mingw32-nm -B output from x86_64-w64-mingw32-gcc object... ok
checking for sysroot... no
checking for a working dd... /usr/bin/dd
checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1
checking for x86_64-w64-mingw32-mt... no
checking for mt... no
checking if : is a manifest tool... no
checking how to run the C preprocessor... x86_64-w64-mingw32-gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if x86_64-w64-mingw32-gcc supports -fno-rtti -fno-exceptions... no
checking for x86_64-w64-mingw32-gcc option to produce PIC... -DDLL_EXPORT -DPIC
checking if x86_64-w64-mingw32-gcc PIC flag -DDLL_EXPORT -DPIC works... yes
checking if x86_64-w64-mingw32-gcc static flag -static works... yes
checking if x86_64-w64-mingw32-gcc supports -c -o file.o... yes
checking if x86_64-w64-mingw32-gcc supports -c -o file.o... (cached) yes
checking whether the x86_64-w64-mingw32-gcc linker (/usr/x86_64-w64-mingw32/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for stdlib.h... (cached) yes
checking for unistd.h... (cached) yes
checking for sys/param.h... yes
checking for getpagesize... yes
checking for working mmap... no
checking for PIC compiler flag... "<none>"
checking for gcc -Wextra... yes
checking for pthread_self in -lpthread... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating doc/Makefile
config.status: creating src/Makefile
config.status: creating tests/Makefile
config.status: creating pkgconfig/atomic_ops.pc
config.status: creating pkgconfig/atomic_ops-uninstalled.pc
config.status: creating src/config.h
config.status: executing depfiles commands
config.status: executing libtool commands
config.status: executing default commands
Making all in src
make[1]: Entering directory '/home/xantares/projects/aur-scripts/mingw-w64-libatomic_ops/src/libatomic_ops-libatomic_ops-7_4_2/build-x86_64-w64-mingw32/src'
make  all-am
make[2]: Entering directory '/home/xantares/projects/aur-scripts/mingw-w64-libatomic_ops/src/libatomic_ops-libatomic_ops-7_4_2/build-x86_64-w64-mingw32/src'
/bin/sh ../libtool  --tag=CC   --mode=compile x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H   -I../src -I../../src   -Wall -Wextra -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4  -MT atomic_ops.lo -MD -MP -MF .deps/atomic_ops.Tpo -c -o atomic_ops.lo ../../src/atomic_ops.c
/bin/sh ../libtool  --tag=CC   --mode=compile x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H   -I../src -I../../src   -Wall -Wextra -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4  -MT atomic_ops_stack.lo -MD -MP -MF .deps/atomic_ops_stack.Tpo -c -o atomic_ops_stack.lo ../../src/atomic_ops_stack.c
libtool: compile:  x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I../src -I../../src -Wall -Wextra -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -MT atomic_ops_stack.lo -MD -MP -MF .deps/atomic_ops_stack.Tpo -c ../../src/atomic_ops_stack.c  -DDLL_EXPORT -DPIC -o .libs/atomic_ops_stack.o
libtool: compile:  x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I../src -I../../src -Wall -Wextra -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -MT atomic_ops.lo -MD -MP -MF .deps/atomic_ops.Tpo -c ../../src/atomic_ops.c  -DDLL_EXPORT -DPIC -o .libs/atomic_ops.o
libtool: compile:  x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I../src -I../../src -Wall -Wextra -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -MT atomic_ops_stack.lo -MD -MP -MF .deps/atomic_ops_stack.Tpo -c ../../src/atomic_ops_stack.c -o atomic_ops_stack.o >/dev/null 2>&1
mv -f .deps/atomic_ops_stack.Tpo .deps/atomic_ops_stack.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H   -I../src -I../../src   -Wall -Wextra -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4  -MT atomic_ops_malloc.lo -MD -MP -MF .deps/atomic_ops_malloc.Tpo -c -o atomic_ops_malloc.lo ../../src/atomic_ops_malloc.c
libtool: compile:  x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I../src -I../../src -Wall -Wextra -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -MT atomic_ops_malloc.lo -MD -MP -MF .deps/atomic_ops_malloc.Tpo -c ../../src/atomic_ops_malloc.c  -DDLL_EXPORT -DPIC -o .libs/atomic_ops_malloc.o
libtool: compile:  x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I../src -I../../src -Wall -Wextra -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -MT atomic_ops_malloc.lo -MD -MP -MF .deps/atomic_ops_malloc.Tpo -c ../../src/atomic_ops_malloc.c -o atomic_ops_malloc.o >/dev/null 2>&1
mv -f .deps/atomic_ops_malloc.Tpo .deps/atomic_ops_malloc.Plo
/bin/sh ../libtool  --tag=CC   --mode=link x86_64-w64-mingw32-gcc  -Wall -Wextra -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4  -version-info 1:3:0 -no-undefined  -o libatomic_ops_gpl.la -rpath /usr/x86_64-w64-mingw32/lib atomic_ops_stack.lo atomic_ops_malloc.lo  
libtool: link: x86_64-w64-mingw32-gcc -shared  .libs/atomic_ops_stack.o .libs/atomic_ops_malloc.o    -O2 -g   -o .libs/libatomic_ops_gpl-1.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libatomic_ops_gpl.dll.a
.libs/atomic_ops_stack.o: In function `AO_stack_pop_explicit_aux_acquire':
/home/xantares/projects/aur-scripts/mingw-w64-libatomic_ops/src/libatomic_ops-libatomic_ops-7_4_2/build-x86_64-w64-mingw32/src/../../src/atomic_ops_stack.c:142: undefined reference to `AO_pause'
collect2: error: ld returned 1 exit status
Makefile:547: recipe for target 'libatomic_ops_gpl.la' failed
make[2]: *** [libatomic_ops_gpl.la] Error 1
make[2]: *** Waiting for unfinished jobs....
libtool: compile:  x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I../src -I../../src -Wall -Wextra -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -MT atomic_ops.lo -MD -MP -MF .deps/atomic_ops.Tpo -c ../../src/atomic_ops.c -o atomic_ops.o >/dev/null 2>&1
mv -f .deps/atomic_ops.Tpo .deps/atomic_ops.Plo
make[2]: Leaving directory '/home/xantares/projects/aur-scripts/mingw-w64-libatomic_ops/src/libatomic_ops-libatomic_ops-7_4_2/build-x86_64-w64-mingw32/src'
Makefile:459: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/home/xantares/projects/aur-scripts/mingw-w64-libatomic_ops/src/libatomic_ops-libatomic_ops-7_4_2/build-x86_64-w64-mingw32/src'
Makefile:473: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

On Linux, ARMv5tel does not have all functions available

It seems that libatomic_ops provides an optimized implementation for ARMv6 and newer architectures. Unfortunately there are no asm functions for ARMv5, which should fallback automatically to the pthread implementation.

This proposed patch is already available in the Fedora package. This change should provide the pthread implementation when atomic_ops.h is included on ARMv5 and earlier architectures.

Please review and include this in the next release if it make sense. Thanks!

Status of 7.6.0?

7.6.0 is over 8 months old now. Is it still considered pre-release?

FTBFS in the testsuite on riscv64

On behalf of Karsten Merker [email protected] (copied from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962917):

libatomic-ops FTBFS on riscv64 due to link failures in the
testsuite. The build log is available at

https://buildd.debian.org/status/fetch.php?pkg=libatomic-ops&arch=riscv64&ver=7.6.10-1&stamp=1588631725&raw=0

The source of the link failures is that the tests aren't built
with the "-pthread" compiler flag.

Some architectures such as riscv64 have native atomics support,
but only for word-sized operands and not for smaller entities.
When called with "-pthread", gcc automatically links in the
necessary wrapper functions to provide the missing atomic
operations on those architectures, but this doesn't happen when
one just links in libpthread with "-lpthread".

Building the tests with "-pthread" in CFLAGS solves the build
failures. It would be great if you could upload a new version
of the package with a corresponding change.

[x86 gcc] Missing dx side effect in AO_compare_double_and_swap_double_full

libatomic_ops/src/atomic_ops/sysdeps/gcc/x86.h

Lines 550 to 562 in ae996e9

	AO_INLINE int
	AO_compare_double_and_swap_double_full(volatile AO_double_t *addr,
	AO_t old_val1, AO_t old_val2,
	AO_t new_val1, AO_t new_val2)
	{
	char result;
	__asm__ __volatile__("lock; cmpxchg16b %0; setz %1"
	: "=m"(*addr), "=a"(result)
	: "m"(*addr), "d" (old_val2), "a" (old_val1),
	"c" (new_val2), "b" (new_val1)
	: "memory");
	return (int) result;
	}

According to https://www.felixcloutier.com/x86/cmpxchg8b:cmpxchg16b, both CMPXCHG8B and CMPXCHG16B may clobber ax and dx if the comparison between old values and memory fails.

Problem. Actually, the compiler is unaware that the value of old_val2 may change between subsequent calls. This issue affects both 32- and 64-bit versions.

For instance, consider the following code:

int main (int argc, char *argv[])
{
  AO_double_t v = 0;
  while (!AO_compare_double_and_swap_double_full(&v,0,1,1,1));
  /* not reachable */
  printf("%#016llx\n", v);
  return 0;
}

(1) it did not infinitely loop as expected (v is not equal to 0x0000000100000000);
(2) due to optimization, it prints 0 where it was at least expected to print 0x0000000100000001.

Solution. An output tied to dx should be added to these blocs:

__asm__ __volatile__("lock; cmpxchg16b %0; setz %1"
                                    : "=m"(*addr), "=a"(result), "=d" (old_val2)
                                    : "m"(*addr), "d" (old_val2), "a" (old_val1),
                                      "c" (new_val2), "b" (new_val1)
                                    : "memory");

Note. It is not the purpose of this issue, but it is not optimal to always return the result in ax. I can see different solutions if you are interested.

Incorrect use of sizeof operator to verify alignment

libatomic_ops incorrectly uses the sizeof operator to verify the correct alignment of an address.

For example, in https://github.com/ivmai/libatomic_ops/blob/master/src/atomic_ops/sysdeps/loadstore/atomic_load.h#L31, we have:

    assert(((size_t)addr & (sizeof(*addr) - 1)) == 0);

This will work only on architectures where the natural alignment is 32 bits or higher, but will fail on architectures like m68k where the natural alignment is 16 bits:

root@pacman:~# debfoster
debfoster: /usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31: AO_load: Assertion `((size_t)addr & (sizeof(*addr) - 1)) == 0' failed.
Aborted
root@pacman:~#

See this discussion: https://lists.debian.org/debian-68k/2020/09/msg00046.html

The proper operator to use would be __alignof__ or alignof (the later requires C11).

Test suite fails to build with gcc-7 on amd64

See downstream bugs https://bugs.gentoo.org/638222 and https://bugs.gentoo.org/641410

libatomic_ops fails to build its test suite on amd64 with gcc-7, where it successfully built with gcc-6.4.0. We've seen undefined references to __atomic_compare_exchange_16, _atomic_load_16, and __atomic_store_16.

riscv support

Are there any plans for adding support for riscv64 / riscv32 platforms?
Can I do anything to help? :)

determining features

Hi, is there a way to see which sysdep has been used in the compiled library? for instance, i'd like to know if when i compile i'm getting something efficient vs the backup mutex implementation.

Support protected mode of E2K

Host: Linux/elbrus-v5 (or later)
Compiler option (to build code in protected mode): -m128
As of current gcc/lcc, there are 2 issues:

• sizeof uintptr_t != sizeof char*
• conversion from pointer to __int128 is not symmetric (a numeric value cannot be converted back to pointer)

The 2nd item is rather hard to workaround (i.e. replace AO_uintptr_t with char* everywhere).

Compiler version: lcc:1.26.20:Jun--6-2023:e2k-v5-linux | gcc (GCC) 9.3.0 compatible

test_stack fail on linux/arm64 (clang)

Build: https://travis-ci.org/github/ivmai/libatomic_ops/jobs/670012675
Source: master (0cb2374)
Compiler: clang version 3.8.0-2ubuntu4
Target: Linux/arm64 (aarch64-unknown-linux-gnu)
How to reproduce: configure --enable-assertions && make -j check CFLAGS_EXTRA="-O3" CC=clang
Reproduction rate: ~1/20

Sparc v8 FTBS

Would it be possible to disable any features that currently depend on Sparc v8+/v9 or implement the missing v8 support code?

I'm building gentoo sparc32 stages and this is an issue I am running into.

>>> Unpacking source...
>>> Unpacking gc-7.2alpha4.tar.gz to /var/tmp/portage/dev-libs/libatomic_ops-7.2_alpha4/work
>>> Source unpacked in /var/tmp/portage/dev-libs/libatomic_ops-7.2_alpha4/work
>>> Preparing source in /var/tmp/portage/dev-libs/libatomic_ops-7.2_alpha4/work/gc-7.2alpha4/libatomic_ops ...
 * Applying libatomic_ops-7.2_alpha4-x32.patch ...                                                                                             [ ok ]
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/dev-libs/libatomic_ops-7.2_alpha4/work/gc-7.2alpha4/libatomic_ops ...
 * econf: updating gc-7.2alpha4/config.guess with /usr/share/gnuconfig/config.guess
 * econf: updating gc-7.2alpha4/config.sub with /usr/share/gnuconfig/config.sub
 * econf: updating gc-7.2alpha4/libatomic_ops/config.guess with /usr/share/gnuconfig/config.guess
 * econf: updating gc-7.2alpha4/libatomic_ops/config.sub with /usr/share/gnuconfig/config.sub
./configure --prefix=/usr --build=sparc-unknown-linux-gnu --host=sparc-unknown-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib --disable-dependency-tracking
checking build system type... sparc-unknown-linux-gnu
checking host system type... sparc-unknown-linux-gnu
checking target system type... sparc-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for sparc-unknown-linux-gnu-ranlib... sparc-unknown-linux-gnu-ranlib
checking for style of include used by make... GNU
checking for sparc-unknown-linux-gnu-gcc... sparc-unknown-linux-gnu-gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether sparc-unknown-linux-gnu-gcc accepts -g... yes
checking for sparc-unknown-linux-gnu-gcc option to accept ISO C89... none needed
checking dependency style of sparc-unknown-linux-gnu-gcc... none
checking whether sparc-unknown-linux-gnu-gcc and cc understand -c and -o together... yes
checking dependency style of sparc-unknown-linux-gnu-gcc... none
checking how to run the C preprocessor... sparc-unknown-linux-gnu-gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for stdlib.h... (cached) yes
checking for unistd.h... (cached) yes
checking for getpagesize... yes
checking for working mmap... yes
checking for ANSI C header files... (cached) yes
checking Determining PIC compiler flag... -fPIC
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating src/atomic_ops/Makefile
config.status: creating src/atomic_ops/sysdeps/Makefile
config.status: creating doc/Makefile
config.status: creating tests/Makefile
config.status: creating src/config.h
config.status: executing depfiles commands
config.status: executing default commands
>>> Source configured.
>>> Compiling source in /var/tmp/portage/dev-libs/libatomic_ops-7.2_alpha4/work/gc-7.2alpha4/libatomic_ops ...
make -j32 AR=sparc-unknown-linux-gnu-ar
Making all in src
make[1]: Entering directory `/var/tmp/portage/dev-libs/libatomic_ops-7.2_alpha4/work/gc-7.2alpha4/libatomic_ops/src'
make  all-recursive
make[2]: Entering directory `/var/tmp/portage/dev-libs/libatomic_ops-7.2_alpha4/work/gc-7.2alpha4/libatomic_ops/src'
Making all in atomic_ops
make[3]: Entering directory `/var/tmp/portage/dev-libs/libatomic_ops-7.2_alpha4/work/gc-7.2alpha4/libatomic_ops/src/atomic_ops'
Making all in sysdeps
make[4]: Entering directory `/var/tmp/portage/dev-libs/libatomic_ops-7.2_alpha4/work/gc-7.2alpha4/libatomic_ops/src/atomic_ops/sysdeps'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/var/tmp/portage/dev-libs/libatomic_ops-7.2_alpha4/work/gc-7.2alpha4/libatomic_ops/src/atomic_ops/sysdeps'
make[4]: Entering directory `/var/tmp/portage/dev-libs/libatomic_ops-7.2_alpha4/work/gc-7.2alpha4/libatomic_ops/src/atomic_ops'
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory `/var/tmp/portage/dev-libs/libatomic_ops-7.2_alpha4/work/gc-7.2alpha4/libatomic_ops/src/atomic_ops'
make[3]: Leaving directory `/var/tmp/portage/dev-libs/libatomic_ops-7.2_alpha4/work/gc-7.2alpha4/libatomic_ops/src/atomic_ops'
make[3]: Entering directory `/var/tmp/portage/dev-libs/libatomic_ops-7.2_alpha4/work/gc-7.2alpha4/libatomic_ops/src'
sparc-unknown-linux-gnu-gcc -DHAVE_CONFIG_H -I.    -fPIC -O2 -pipe -mcpu=v8 -DNDEBUG -c atomic_ops.c
sparc-unknown-linux-gnu-gcc -DHAVE_CONFIG_H -I.    -fPIC -O2 -pipe -mcpu=v8 -DNDEBUG -c atomic_ops_stack.c
sparc-unknown-linux-gnu-gcc -DHAVE_CONFIG_H -I.    -fPIC -O2 -pipe -mcpu=v8 -DNDEBUG -c atomic_ops_malloc.c
atomic_ops_malloc.c: In function ‘msb’:
atomic_ops_malloc.c:223:2: warning: right shift count >= width of type [enabled by default]
{standard input}: Assembler messages:
{standard input}:35: Error: Architecture mismatch on "membar".
{standard input}:35:  (Requires v9|v9a|v9b; requested architecture is v8.)
{standard input}:36: Error: Architecture mismatch on "cas".
{standard input}:36:  (Requires v9|v9a|v9b; requested architecture is v8.)
{standard input}:37: Error: Architecture mismatch on "membar".
{standard input}:37:  (Requires v9|v9a|v9b; requested architecture is v8.)
{standard input}:72: Error: Architecture mismatch on "membar".
{standard input}:72:  (Requires v9|v9a|v9b; requested architecture is v8.)
{standard input}:73: Error: Architecture mismatch on "cas".
{standard input}:73:  (Requires v9|v9a|v9b; requested architecture is v8.)
{standard input}:74: Error: Architecture mismatch on "membar".
{standard input}:74:  (Requires v9|v9a|v9b; requested architecture is v8.)
{standard input}:95: Error: Architecture mismatch on "membar".
{standard input}:95:  (Requires v9|v9a|v9b; requested architecture is v8.)
{standard input}:96: Error: Architecture mismatch on "cas".
{standard input}:96:  (Requires v9|v9a|v9b; requested architecture is v8.)
{standard input}:97: Error: Architecture mismatch on "membar".
{standard input}:97:  (Requires v9|v9a|v9b; requested architecture is v8.)
{standard input}:131: Error: Architecture mismatch on "membar".
{standard input}:131:  (Requires v9|v9a|v9b; requested architecture is v8.)
{standard input}:132: Error: Architecture mismatch on "cas".
{standard input}:132:  (Requires v9|v9a|v9b; requested architecture is v8.)
{standard input}:133: Error: Architecture mismatch on "membar".
{standard input}:133:  (Requires v9|v9a|v9b; requested architecture is v8.)
make[3]: *** [atomic_ops_stack.o] Error 1
make[3]: *** Waiting for unfinished jobs....
{standard input}: Assembler messages:
{standard input}:149: Error: Architecture mismatch on "membar".
{standard input}:149:  (Requires v9|v9a|v9b; requested architecture is v8.)
{standard input}:150: Error: Architecture mismatch on "cas".
{standard input}:150:  (Requires v9|v9a|v9b; requested architecture is v8.)
{standard input}:151: Error: Architecture mismatch on "membar".
{standard input}:151:  (Requires v9|v9a|v9b; requested architecture is v8.)
{standard input}:167: Error: Architecture mismatch on "membar".
{standard input}:167:  (Requires v9|v9a|v9b; requested architecture is v8.)
{standard input}:168: Error: Architecture mismatch on "cas".
{standard input}:168:  (Requires v9|v9a|v9b; requested architecture is v8.)
{standard input}:169: Error: Architecture mismatch on "membar".
{standard input}:169:  (Requires v9|v9a|v9b; requested architecture is v8.)
make[3]: *** [atomic_ops_malloc.o] Error 1
make[3]: Leaving directory `/var/tmp/portage/dev-libs/libatomic_ops-7.2_alpha4/work/gc-7.2alpha4/libatomic_ops/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/var/tmp/portage/dev-libs/libatomic_ops-7.2_alpha4/work/gc-7.2alpha4/libatomic_ops/src'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/var/tmp/portage/dev-libs/libatomic_ops-7.2_alpha4/work/gc-7.2alpha4/libatomic_ops/src'
make: *** [all-recursive] Error 1

How can I get libatomic_ops.a ?

In Centos 7.4, when compiling nginx with the --with-libatomic=/usr/local/src/libatomic_ops-7.6.4 option, it is reported that libatomic_ops.a does not exist.

test_atomic fail with 'Saw release store out of order' on ppc64

Source: master (400a88b)
Build: https://app.travis-ci.com/github/ivmai/libatomic_ops/jobs/611939900
Host: Ubuntu 22.04.2 LTS / ppc64le
Compiler: gcc (Ubuntu 11.3.0-1ubuntu1~22.04.1) 11.3.0
Config: CMAKE_OPTIONS="-DCMAKE_BUILD_TYPE=MinSizeRel -Denable_assertions=ON -Denable_atomic_intrinsics=OFF"
Occurrence: ~3/4
Output (test_atomic):
Saw release store out of order (bad CSE?): 2026939 < 2027014

test_stack fail on E2K in 64-bit mode

Source: master (30db756)
Host: Linux ... 5.4.0-6.9-e8c #1 SMP ... e2k E8C E8C-SWTX GNU/Linux
Compiler: lcc:1.26.20:Jun--6-2023:e2k-v4-linux (gcc (GCC) 9.3.0 compatible)
How to reproduce: ./autogen.sh && ./configure && make check CFLAGS_EXTRA="-m64 -D AO_PREFER_BUILTIN_ATOMICS" LDFLAGS="-latomic"
Output (tests/test_stack.log):
Failed - nothing to pop

gcc on windows

just a question - does it work with gcc on Windows, both in cygwin and not?
Thanks!

missing prototype on gcc/s390x

Hi, I'm facing the problem that the prototypes for AO_fetch_compare_and_swap_full and AO_fetch_compare_and_swap_emulation are not defined.

Test:

#define AO_REQUIRE_CAS
#include <atomic_ops.h>

int main() {
    void *addr;
    AO_t foo;
    AO_fetch_and_add1_full((volatile AO_t *)addr);
    AO_fetch_and_sub1_full((volatile AO_t *)addr);
    AO_fetch_and_add_full((volatile AO_t *)addr, foo);
    AO_compare_and_swap_full((volatile AO_t *)addr, foo, foo);
    AO_fetch_compare_and_swap_full(addr, foo, foo);
    AO_nop_full();
    AO_store_full((volatile AO_t *)addr, foo);
    AO_load_full((volatile AO_t *)addr);

    return 0;
}

Command to compile:

gcc -o test test.c -latomic_ops

Result:

test.c: In function 'main':
test.c:12:5: warning: implicit declaration of function 'AO_fetch_compare_and_swap_full' [-Wimplicit-function-declaration]
     AO_fetch_compare_and_swap_full(addr, foo, foo);
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/ccyHNYEp.o: In function `main':
test.c:(.text+0x35c): undefined reference to `AO_fetch_compare_and_swap_full'
collect2: error: ld returned 1 exit status

Symbols in the library:

$ nm /usr/lib/s390x-linux-gnu/libatomic_ops.a 

atomic_ops.o:
00000000000001c0 T AO_compare_double_and_swap_double_emulation
0000000000000358 T AO_fetch_compare_and_swap_emulation
0000000000000000 B AO_locks
0000000000000000 T AO_pause
0000000000000080 B AO_pt_lock
0000000000000148 T AO_store_full_emulation
                 U __stack_chk_fail
00000000000000b8 b all_sigs
00000000000000a8 b init_lock
00000000000000b0 b initialized
00000000000000e0 t lock_ool
                 U select
                 U sigfillset
                 U sigprocmask
0000000000000000 d spin_dummy

(The example code is also available at https://github.com/FROGGS/libatomic-ops-test, so one would just need to clone and make).

The installed libatomic_ops lib is from debian unstable:

$ apt-cache show libatomic-ops-dev
Package: libatomic-ops-dev
Source: libatomic-ops
Version: 7.4.4-1

What would be the correct solution?
Shall AO_CAN_EMUL_CAS be defined for s390x? ('cause it currently isnt)
Though, defining it before including atomic_ops.h sadly makes no difference.

configure AC_FUNC_MMAP does not detect mmap on CheriBSD

Source: master (30db756)
Host: Morello CheriBSD / arm64 (FreeBSD 14.0)
How to reproduce: ./configure | grep "checking for working mmap"
Output: checking for working mmap... no
Reported in CHERI project: CTSRD-CHERI/cheribsd-ports#122

Known workaround: change "undef HAVE_MMAP" to "define HAVE_MMAP" in src/config.h.

AArch64: Shareability domain for dmb st overly conservative

Hello,
In src/atomic_ops/sysdeps/gcc/aarch64.h, we have the following code:
__asm__ __volatile__("dmb st" : : : "memory");

This will target the system domain and thus be overly conservative as the CPUs will occupy the inner shareable domain.

Could this please be changed to:
__asm__ __volatile__("dmb ishst" : : : "memory");

That way the barriers will occupy the inner shareable domain.

Thanks,
Steve Capper

Undefined reference to AO_pt_lock on Ubuntu 22.04 when building with configure and clang-16

Build: https://app.travis-ci.com/github/ivmai/libatomic_ops/jobs/602706880
Source: master (3e53e26)
Host: Ubuntu 22.04 / x64
Compiler: clang version 16.0.0 ; Target: x86_64-unknown-linux-gnu ; Thread model: posix
How to build: ./autogen.sh && ./configure --enable-werror && make check CFLAGS_EXTRA="-D AO_USE_PTHREAD_DEFS"
Output:

clang -Werror -Wall -Wextra -Wpedantic -Wno-long-long -g -O2 -D AO_USE_PTHREAD_DEFS -o test_malloc test_malloc.o  ../src/.libs/libatomic_ops_gpl.a /home/travis/build/ivmai/libatomic_ops/src/.libs/libatomic_ops.a
/usr/bin/ld: test_stack.o: in function `run_one_test':
test_stack.c:(.text+0x21a): undefined reference to `AO_pt_lock'
/usr/bin/ld: ../src/.libs/libatomic_ops_gpl.a(atomic_ops_stack.o): in function `AO_stack_push_release':
atomic_ops_stack.c:(.text+0x52): undefined reference to `AO_pt_lock'
/usr/bin/ld: atomic_ops_stack.c:(.text+0x93): undefined reference to `AO_pt_lock'
/usr/bin/ld: atomic_ops_stack.c:(.text+0xef): undefined reference to `AO_pt_lock'

How to reproduce: ./configure --enable-werror && clang-16 -DHAVE_CONFIG_H -I src -D AO_USE_PTHREAD_DEFS tests/test_atomic.c src/*.c

build error on OS X 10.7: Cannot implement AO_compare_and_swap_full on this architecture

When building the version from master on OS X 10.7, it fails with

libtool: compile:  /usr/bin/clang -DHAVE_CONFIG_H -I../src -I../src -I/opt/local/include -fPIC -Wall -Wextra -Wpedantic -Wno-long-long -pipe -Os -arch x86_64 -MT atomic_ops.lo -MD -MP -MF .deps/atomic_ops.Tpo -c atomic_ops.c -o atomic_ops.o
In file included from atomic_ops_stack.c:23:
In file included from ../src/atomic_ops_stack.h:32:
../src/atomic_ops.h:383:5: error: Cannot implement AO_compare_and_swap_full on this architecture.
#   error Cannot implement AO_compare_and_swap_full on this architecture.
    ^
1 error generated.

Version 7.4.4 works fine.

Output from configure:

checking build system type... x86_64-apple-darwin11.4.2
checking host system type... x86_64-apple-darwin11.4.2
checking target system type... x86_64-apple-darwin11.4.2
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /opt/local/bin/gmkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for style of include used by make... GNU
checking for gcc... /usr/bin/clang
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether /usr/bin/clang accepts -g... yes
checking for /usr/bin/clang option to accept ISO C89... none needed
checking whether /usr/bin/clang understands -c and -o together... yes
checking dependency style of /usr/bin/clang... gcc3
checking dependency style of /usr/bin/clang... gcc3
checking how to print strings... printf
checking for a sed that does not truncate output... /opt/local/bin/gsed
checking for grep that handles long lines and -e... /opt/local/bin/grep
checking for egrep... /opt/local/bin/grep -E
checking for fgrep... /opt/local/bin/grep -F
checking for ld used by /usr/bin/clang... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... no
checking for BSD- or MS-compatible name lister (nm)... /opt/local/bin/nm
checking the name lister (/opt/local/bin/nm) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 196608
checking how to convert x86_64-apple-darwin11.4.2 file names to x86_64-apple-darwin11.4.2 format... func_convert_file_noop
checking how to convert x86_64-apple-darwin11.4.2 file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... no
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... no
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /opt/local/bin/nm output from /usr/bin/clang object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking for dsymutil... dsymutil
checking for nmedit... nmedit
checking for lipo... lipo
checking for otool... otool
checking for otool64... no
checking for -single_module linker flag... yes
checking for -exported_symbols_list linker flag... yes
checking for -force_load linker flag... yes
checking how to run the C preprocessor... /usr/bin/clang -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if /usr/bin/clang supports -fno-rtti -fno-exceptions... yes
checking for /usr/bin/clang option to produce PIC... -fno-common -DPIC
checking if /usr/bin/clang PIC flag -fno-common -DPIC works... yes
checking if /usr/bin/clang static flag -static works... no
checking if /usr/bin/clang supports -c -o file.o... yes
checking if /usr/bin/clang supports -c -o file.o... (cached) yes
checking whether the /usr/bin/clang linker (/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin11.4.2 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... no
checking whether to build static libraries... yes
checking for stdlib.h... (cached) yes
checking for unistd.h... (cached) yes
checking for sys/param.h... yes
checking for getpagesize... yes
checking for working mmap... yes
checking for PIC compiler flag... -fPIC
checking whether gcc -fPIC causes __PIC__ definition... yes
checking for gcc -Wextra... yes
checking for gcc -Wpedantic... yes
checking for pthread_self in -lpthread... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating doc/Makefile
config.status: creating src/Makefile
config.status: creating tests/Makefile
config.status: creating pkgconfig/atomic_ops.pc
config.status: creating pkgconfig/atomic_ops-uninstalled.pc
config.status: creating src/config.h
config.status: executing depfiles commands
config.status: executing libtool commands
config.status: executing default commands

Using a newer compiler like clang-3.4 helps though.

Release request for mips64el support

Hi,

I recently updated Debian package to 7.4.4 and must have misread the history, because I thought that all the mips64el patches were in that branch, but I guess not so

From the bug report [1] you can see I missed

• Remove 0001-Use-LLD-and-SCD-instructions-on-mips64.patch (54d1da5)
• Remove 004-Support-n32-ABI-for-mips64.patch (d3e884b)

I'd much prefer to just be in sync with upstream than carry patches in the package. Do you think we could get these into a 7.4.5 release which I could update the package to?

Thanks,

-i

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773205

Annoying warning (‘-pedantic’ is not an option that controls warnings)

Hi. When I compile this repo. from nginx, I get this minor warning:

checking for strnlen... In file included from atomic_ops.c:78:0:
atomic_ops/sysdeps/standard_ao_double_t.h:35:37: warning: ‘-pedantic’ is not an option that controls warnings [-Wpragmas]
 #     pragma GCC diagnostic ignored "-pedantic"
                                     ^~~~~~~~~~~

Maybe It could be relevant? Or not.

Explore existing changes in forks (Nov 2021)

https://github.com/ivmai/libatomic_ops/network/members : the following forks have commits ahead of upstream master:

• https://github.com/DawidvC/libatomic_ops - 3
• https://github.com/Distrotech/libatomic_ops - 1
• https://github.com/ffabbri4/libatomic_ops - 1
• https://github.com/FROGGS/libatomic_ops - 1
• https://github.com/ibinti/bugvm-libatomic_ops - 1
• https://github.com/Kelledin/libatomic_ops - 1
• https://github.com/mkloeppner/bugvm-libatomic_ops - 1
• https://github.com/praiskup/libatomic_ops - 1
• https://github.com/romance-ii/libatomic_ops - 1
• https://github.com/Unity-Technologies/libatomic_ops - 13
• https://github.com/val-verde/libatomic_ops - 139
• https://github.com/wiltonlazary/bugvm-libatomic_ops - 1

Option to omit documentation at install

Reported by @concatime (#27) : could you provide an option to install only shared libraries like here, it would be really useful for a lot of us.

Invalid instruction in test_stack on E2K-v5 in protected mode

Source: 7279f81 (master)
Host: Linux/e2k-v5
Linux kernel: 5.4.0-6.9-e8c2
Compiler: lcc:1.26.22:Jan-10-2024:e2k-v5-linux (gcc (GCC) 9.3.0 compatible)
How to reproduce: ./configure --enable-assertions && make -j check CFLAGS_EXTRA="-O0 -g -m128" && tests/test_stack
Occurrence: ~1/15 (higher occurrence if compiled with -O3)

Related: #61 #59

test_stack failed on POWER7

RHELinux6/POWER7 (gcc-4.4.7-3/ppc64), Fedora16/POWER7 (gcc-4.6.2-1/ppc64),
Debian/powerpc (gcc 4.6.3-7):
test_stack failed (Debian Bug #680100).

Bug reported by Will Schmidt [email protected] (Feb 1, 2014)

Downstream libatomic_ops release (Mar 2023)

Just convenient place to keep record of pushing latest releases downstream.

https://github.com/ivmai/libatomic_ops/releases/download/v7.8.0/libatomic_ops-7.8.0.tar.gz
file_size: 526300
md5: a7e51e8041c3e60c298c037b2789c3fa
sha1: 69223bbec025a0d57977feb861479f78a5e6c8d7
sha256: 15676e7674e11bda5a7e50a73f4d9e7d60452271b8acf6fd39a71fefdf89fa31
sha512: b0d2b3c6f8672d599e05087688e7793a3c648c1728f48b27bffecc95b70afd5921ed36ec016985b2e22b82de7b7013bf5ebbb8b434a736d3fd680310b7af903d
cksum (linux): 596151076

[1] https://repology.org/project/libatomic-ops/history
[2] Previous task: #53

SIGSEGV in test_malloc on Alpine linux/s390x

As part of Alpine Linux's (musl libc) packaging process we run make check. Unfortunately test_malloc fails on s390x:

================================================
   libatomic_ops 7.6.10: tests/test-suite.log
================================================

# TOTAL: 5
# PASS:  4
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: test_malloc
=================

Performing 1000 reversals of 1000 element lists in 16 threads
Segmentation fault (core dumped)
FAIL test_malloc (exit status: 139)

btw Travis CI also supports arm64, ppc64le and s390x - https://config.travis-ci.com/ref/arch

coredump with '__atomic_fetch_add' function on aarch64

nginx run on aarch64 ,core dump,gcc 7.3.0:
AO_INLINE AO_t
AO_fetch_and_add(volatile AO_t *addr, AO_t incr)
{
return __atomic_fetch_add(addr, incr, __ATOMIC_RELAXED);
}

cas ptr

The header says "All operations operate on unsigned AO_t, which is the natural word size, and usually unsigned long".

Does this mean it can't CAS a pointer, or that it can? The APR has
apr underscore atomic underscore casptr
see http://apr.apache.org/docs/apr/trunk/group double underscore apr double underscore atomic.html
, which works for me on 64-bit. But I'm looking at using this library instead for the atomic operations because of the memory barrier precision. So I'm just wondering whether this library will let me CAS pointers on 64-bit.

Thanks again!

test_malloc abort on sparc

Source: master (69e1880)
Host: Linux 5.18.0-3-sparc64-smp (Debian)
Compiler: clang 13.0.1
How to build: CC=clang ./configure --enable-assertions --disable-atomic-intrinsics && make -j check
Fail rate: ~3/4
Note: cannot reproduce with gcc-12

Output 1 (test_malloc):
Performing 1000 reversals of 1000 element lists in 16 threads
Testing AO_malloc/AO_free
Aborted

Output 2 (test_malloc):
Performing 1000 reversals of 1000 element lists in 16 threads
Testing AO_malloc/AO_free
Segmentation fault

Some related issue: #44 (a SIGSEGV in test_malloc on some other arch)

test_stack failed on Debian/m68k

Debian/m68k (Linux 3.2.0-2-atari):
test_stack failed (Bus error), regression (Debian Bug #680066).

Bug reported by Thorsten Glaser [email protected] (Nov 21, 2012)

Downstream libatomic_ops releases (Aug 2022)

Just convenient place to keep record of pushing latest releases downstream.

https://github.com/ivmai/libatomic_ops/releases/download/v7.6.14/libatomic_ops-7.6.14.tar.gz
file_size: 500006
md5: ee8251f5091b7938d18be4dda843a515
sha1: 6385dc214e48f70a501c334d4143ead98b171f31
sha256: 390f244d424714735b7050d056567615b3b8f29008a663c262fb548f1802d292
sha512: da83886b4d766da64b27672eede40bd5787523a4c308ac7bd3f03ac831ae1a141ba21e5f5ada27bfcf811b9fb04d8a519331ea2573af036f8791958668dad851
cksum (linux): 3394828912

[1] https://repology.org/project/libatomic-ops/history
[2] Previous task: #49

Downstream libatomic_ops releases (Sep 2021)

Just convenient place to keep record of pushing latest releases downstream.

• https://github.com/ivmai/libatomic_ops/releases/download/v7.6.12/libatomic_ops-7.6.12.tar.gz
  file_size: 506313
  md5: 0b0b88da4bde5dd770daea3146e78359
  sha1: 8d4c69e8b2ed098ce4e056170fd96fc590c2b885
  sha256: f0ab566e25fce08b560e1feab6a3db01db4a38e5bc687804334ef3920c549f3e
  sha512: bbf98a38a80c8fe6b7eab773967edc55b8d48be32b36ed827fb835ee3dcd96d5ec1dc97149714e015e93a0a5b9fc03595797663fdb5a0f673869ea8bfe640df5
  cksum (linux): 3123545103

[1] https://repology.org/project/libatomic-ops/packages

Downstream libatomic_ops v7.8.2

Just convenient place to keep record of pushing latest release downstream.

https://github.com/ivmai/libatomic_ops/releases/download/v7.8.2/libatomic_ops-7.8.2.tar.gz
file_size: 524637
md5: d07b3d8369d7f9efdca59f7501dd1117
sha1: aaa44f2b182a05a7cdc6778a0f26976cc925acfe
sha256: d305207fe207f2b3fb5cb4c019da12b44ce3fcbc593dfd5080d867b1a2419b51
sha512: 0559087c99b941990f189ea4ed5b3b371faf086bc1d517da6b878ba609c200eef24358768fd4361900101cdb474e28cea8408eb0b0222d23ef3154ce77f6acc0
cksum (linux): 4269091898

[1] https://repology.org/project/libatomic-ops/history
[2] Previous task: #56

msftc x86 compare_and_swap_full

I'm curious why compare_and_swap_full is not implemented for x86/msftc. Is it unavailable?