[Bug 230888] Missing 64 bit atomic functions for i386

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230888

            Bug ID: 230888
           Summary: Missing 64 bit atomic functions for i386
           Product: Base System
           Version: CURRENT
          Hardware: i386
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: bin
          Assignee: bugs at FreeBSD.org
          Reporter: dim at FreeBSD.org

We have always been missing 64 bit atomic functions for i386, and this issue
has now unfortunately come up again when testing llvm 7.0.0 release
candidates[1].

Our old gcc 4.2 never supported the necessary C11 constructs, so it was never a
problem there.  But since clang has been introduced, it has silently emitted
"lock cmpxchg8b" instructions, even though these are only supported by i586 and
higher CPUs.

Upstream llvm attempted to fix this a number of times, most recently in
<https://reviews.llvm.org/rL323281>.  However, for the default target CPU on
i386-freebsd, which is i486, it will be forced to emit function calls to atomic
primitives, as __atomic_load_8(), __atomic_fetch_add_8() and such.

Demonstration with ports gcc:

$ cat test-c11-atomic-2.c
_Atomic(long long) ll;

int main(void)
{
        ++ll;
        return 0;
}

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc8/gcc/i386-portbld-freebsd12.0/8.2.0/lto-wrapper
Target: i386-portbld-freebsd12.0
Configured with: /wrkdirs/share/dim/ports/lang/gcc8/work/gcc-8.2.0/configure
--disable-multilib --disable-bootstrap --disable-nls
--enable-gnu-indirect-function --libdir=/usr/local/lib/gcc8
--libexecdir=/usr/local/libexec/gcc8 --program-suffix=8
--with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc8/include/c++/
--with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection'
--with-system-zlib --with-isl=/usr/local --enable-languages=c,c++,objc,fortran
--prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man
--infodir=/usr/local/info/gcc8 --build=i386-portbld-freebsd12.0
Thread model: posix
gcc version 8.2.0 (FreeBSD Ports Collection)

$ gcc -O2 -S test-c11-atomic-2.c -o -
        .file   "test-c11-atomic-2.c"
        .text
        .section        .text.startup,"ax", at progbits
        .p2align 4,,15
        .globl  main
        .type   main, @function
main:
.LFB0:
        .cfi_startproc
        leal    4(%esp), %ecx
        .cfi_def_cfa 1, 0
        andl    $-16, %esp
        pushl   -4(%ecx)
        pushl   %ebp
        .cfi_escape 0x10,0x5,0x2,0x75,0
        movl    %esp, %ebp
        pushl   %ecx
        .cfi_escape 0xf,0x3,0x75,0x7c,0x6
        subl    $4, %esp
        pushl   $5
        pushl   $0
        pushl   $1
        pushl   $ll
        call    __atomic_fetch_add_8
        movl    -4(%ebp), %ecx
        .cfi_def_cfa 1, 0
        addl    $16, %esp
        xorl    %eax, %eax
        leave
        .cfi_restore 5
        leal    -4(%ecx), %esp
        .cfi_def_cfa 4, 4
        ret
        .cfi_endproc
.LFE0:
        .size   main, .-main
        .comm   ll,8,8
        .ident  "GCC: (FreeBSD Ports Collection) 8.2.0"
        .section        .note.GNU-stack,"", at progbits

$ gcc -O2 test-c11-atomic-2.c
/tmp//cc4hCSj6.o: In function `main':
test-c11-atomic-2.c:(.text.startup+0x1d): undefined reference to
`__atomic_fetch_add_8'
collect2: error: ld returned 1 exit status

We should really make a choice and either:
1) Implement __atomic_load_8, __atomic_fetch_8 and others for i386, with or
without kernel support, and add them to libc or libgcc
2) Change the default target CPU to i586 (which is actually the de facto
default for a few years now), or even i686.

I assume 1) is quite a lot of work, so 2) is likely the way of least effort,
but might meet with some resistance to change and POLA complaints.

[1] http://lists.llvm.org/pipermail/release-testers/2018-August/000753.html
[2] https://reviews.llvm.org/rL323281

-- 
You are receiving this mail because:
You are the assignee for the bug.