Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 25 Aug 2018 12:53:48 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 230888] Missing 64 bit atomic functions for i386
Message-ID:  <bug-230888-227@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230888

            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@FreeBSD.org
          Reporter: dim@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 nev=
er 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 at=
omic
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=3Dgcc
COLLECT_LTO_WRAPPER=3D/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=3D/usr/local/lib/gcc8
--libexecdir=3D/usr/local/libexec/gcc8 --program-suffix=3D8
--with-as=3D/usr/local/bin/as --with-gmp=3D/usr/local
--with-gxx-include-dir=3D/usr/local/lib/gcc8/include/c++/
--with-ld=3D/usr/local/bin/ld --with-pkgversion=3D'FreeBSD Ports Collection'
--with-system-zlib --with-isl=3D/usr/local --enable-languages=3Dc,c++,objc,=
fortran
--prefix=3D/usr/local --localstatedir=3D/var --mandir=3D/usr/local/man
--infodir=3D/usr/local/info/gcc8 --build=3Di386-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",@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,"",@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

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-230888-227>