From owner-freebsd-bugs@freebsd.org Sat Aug 25 12:53:50 2018 Return-Path: Delivered-To: freebsd-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 627131089E9E for ; Sat, 25 Aug 2018 12:53:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 00AFF96F4F for ; Sat, 25 Aug 2018 12:53:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id B95741089E9C; Sat, 25 Aug 2018 12:53:49 +0000 (UTC) Delivered-To: bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 977F41089E9A for ; Sat, 25 Aug 2018 12:53:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 37C0F96F4D for ; Sat, 25 Aug 2018 12:53:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 8567B1B455 for ; Sat, 25 Aug 2018 12:53:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w7PCrmCd033594 for ; Sat, 25 Aug 2018 12:53:48 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w7PCrmWx033593 for bugs@FreeBSD.org; Sat, 25 Aug 2018 12:53:48 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 230888] Missing 64 bit atomic functions for i386 Date: Sat, 25 Aug 2018 12:53:48 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 12:53:50 -0000 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 . 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.=