From owner-freebsd-bugs@freebsd.org Sun Nov 1 12:04:11 2020 Return-Path: Delivered-To: freebsd-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id F1F2644B8DB for ; Sun, 1 Nov 2020 12:04:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4CPF8C6D80z43tb for ; Sun, 1 Nov 2020 12:04:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id D588B44BD17; Sun, 1 Nov 2020 12:04:11 +0000 (UTC) Delivered-To: bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D54E944BCD2 for ; Sun, 1 Nov 2020 12:04:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CPF8C5LZ0z448K for ; Sun, 1 Nov 2020 12:04:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 9999018689 for ; Sun, 1 Nov 2020 12:04:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 0A1C4Boc084288 for ; Sun, 1 Nov 2020 12:04:11 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 0A1C4B6i084287 for bugs@FreeBSD.org; Sun, 1 Nov 2020 12:04:11 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 250755] 12.2-RELEASE i386 GENERIC kernel fails to load Date: Sun, 01 Nov 2020 12:04:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me 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: cc Message-ID: In-Reply-To: References: 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.33 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2020 12:04:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D250755 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |arichardson@FreeBSD.org --- Comment #4 from Dimitry Andric --- The bump to i686 was originally committed to head in base r353936, after ba= se r352030 bumped it to i586 at first. On 2020-01-07, so already 11 months ago, this was all merged back to stable/12 in base r356460, as part of the clang 9.0.0 merge. Similarly, on 2020-05-05 for stable/11, in base r360658. In any case, I have tried buiding stable/12 world with base r353936 and base r352030 reverted, so effectively going back to i486 as default: Index: contrib/llvm-project/clang/lib/Driver/ToolChains/Arch/X86.cpp =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- contrib/llvm-project/clang/lib/Driver/ToolChains/Arch/X86.cpp=20=20=20= =20=20=20 (revision 367228) +++ contrib/llvm-project/clang/lib/Driver/ToolChains/Arch/X86.cpp=20=20=20= =20=20=20 (working copy) @@ -94,7 +94,7 @@ switch (Triple.getOS()) { case llvm::Triple::FreeBSD: - return "i686"; + //return "i686"; FALLTHROUGH case llvm::Triple::NetBSD: case llvm::Triple::OpenBSD: return "i486"; However, this leads to a -Werror problem again: --- atomic.o --- /usr/src/contrib/llvm-project/compiler-rt/lib/builtins/atomic.c:178:3: erro= r: large atomic operation may incur significant performance penalty [-Werror,-Watomic-alignment] LOCK_FREE_CASES(); ^ /usr/src/contrib/llvm-project/compiler-rt/lib/builtins/atomic.c:160:9: note: expanded from macro 'LOCK_FREE_CASES' LOCK_FREE_ACTION(uint64_t);=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 \ ^ /usr/src/contrib/llvm-project/compiler-rt/lib/builtins/atomic.c:176:21: not= e: expanded from macro 'LOCK_FREE_ACTION' *((type *)dest) =3D __c11_atomic_load((_Atomic(type) *)src, model);=20=20= =20=20=20=20=20=20=20=20=20 \ ^ 1 error generated. *** [atomic.o] Error code 1 Originally we have -Wno-atomic-alignment in libcompiler_rt's Makefile, but = we removed it base r364782, because: > After base r364753, there should be no need to suppress -Watomic-alignment > warnings anymore for compiler-rt's atomic.c. This occurred because the > IS_LOCK_FREE_8 macro was not correctly defined to 0 for mips, and this > caused the compiler to emit a runtime call to __atomic_is_lock_free(), > and that triggers the warning. However, the changes in base r364753 are not enough for this particular warning. Alex, you also worked on these warnings upstream, right? I think = we could probably add __i386__ to the following line in contrib/llvm-project/compiler-rt/lib/builtins/atomic.c to work around it (optionally with a check if the target CPU is really < i586): /// 32 bit MIPS and PowerPC don't support 8-byte lock_free atomics #if defined(__mips__) || (!defined(__powerpc64__) && defined(__powerpc__)) --=20 You are receiving this mail because: You are the assignee for the bug.=