From owner-svn-src-head@freebsd.org Wed Aug 1 01:46:36 2018 Return-Path: Delivered-To: svn-src-head@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 D6D9E106C6D1 for ; Wed, 1 Aug 2018 01:46:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-12.consmr.mail.ne1.yahoo.com (sonic307-12.consmr.mail.ne1.yahoo.com [66.163.190.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6566E8DC5B for ; Wed, 1 Aug 2018 01:46:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: AmAk3AMVM1nj3.KdGSoy.C9GIdTViRbWmwHXGTRvVJC9UHGZjxDciEk7XvVnINx qfGlKAB__xqm5pdM.ta3aE.jI3k94Y.JQqnGkUf7sZsUPqmtrvN1xzv8Cz4zAfO036BOkT_4slX7 ylBd5mkcxAx3R8Bjs7YbLHLLlzrqv0OKqKG_lbFpmPSm4thkgtDSU2OM9eY6ibliXHUT9D3wqgeQ 76j8frSPT3fULoWYPJsMu5gtMjUZFO9LkNu4I4VKH1scc9KCcLu4p.JujHSTx.rf919xGYKYm2v5 bFSKs_c1doFVhBtcCE3pyW79lugMcG7qtMgtUffBCfr7eND.PrpVeGZ.aL8x8HvphGylTYS_jP2B ll2JXi0heXS2qY6YxLRwfOYcW9V5Ci5RxZfXp39qoqQk8cN6MpES4_XFSBtpF3lenUUSNWqTB_7E Qme61qGEZ2dRYI1bA.BKyIBbQvYWrnaiKXwrsQXVcukODguDzHN_CsukS6IM5rWTK4CFbm5Us0s6 qdCdJp6LBYCmTJ0bxM4.iVOJGuao04g2NEUDODiTXisZlcgFUmeDw6f6m9JBS2rF0lfhChhF6.SP Bjv2LtHnWSR6fPmwqwpyI23XAABF1V_RYaJ_PNPnzBiFy1SHetalDVPVTeGu7Gq9yGdKC4.kwFPA 4vLgWpthEBOixOqrh9IdjxV2a1S91LIM5OktplkLxc6ETzvb70ekSkPrAVK0tumJBwIRqqmfEpLZ 3QRq7n3aSihq_SFUfjxoZGZ2lty6.ZueBDI4VDJeIwnJ4BcW8SqxElEfwH5OQT.KSWVGow8yEMf1 OttbB0vp5iNczy1fHUM29Ya2D1M8VQN83pQ2fKTUQL5_Nnp9miBm9gDiS.NUq05B709CVyyMXTWI 35bScd68dluT3DRCX1ClJOf7xhahXROZ5lVKHIvdiPv7Jz5jmxCCeKz7B_Ynv.SOau.pZalpC5yb 4.zmv8xmwV29nJM9zFncTCGxjiV_UrGT44066BDRONPwEy1BN3CMzTsNMPvCaVQydVXlJi3j5Vl5 LxnYEEjGQByPOVrFK Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ne1.yahoo.com with HTTP; Wed, 1 Aug 2018 01:46:34 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp425.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 8038f0495d12a8775d8b876066527fc5; Wed, 01 Aug 2018 01:46:33 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: svn commit: r335873 - in head: . sys/amd64/amd64 sys/amd64/include sys/conf sys/i386/i386 sys/i386/include sys/sys sys/vm Message-Id: <226713AF-FC51-4A44-93E1-8264B1BD2C8A@yahoo.com> Date: Tue, 31 Jul 2018 18:46:31 -0700 To: mmacy@FreeBSD.org, svn-src-head@freebsd.org, freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 01:46:36 -0000 > Author: mmacy > Date: Mon Jul 2 19:48:38 2018 > New Revision: 335873 > URL:=20 > https://svnweb.freebsd.org/changeset/base/335873 >=20 >=20 > Log: > inline atomics and allow tied modules to inline locks > =20 > - inline atomics in modules on i386 and amd64 (they were always > inline on other arches) > - allow modules to opt in to inlining locks by specifying > MODULE_TIED=3D1 in the makefile I recently found the following about ABI incompatibilities between clang and gcc relative to C11 language based atomics: https://bugs.llvm.org/show_bug.cgi?id=3D26462 26462 =E2=80=93 GCC/clang C11 _Atomic incompatibility So are there implications about building the kernel vs. modules that overall mix the toolchains once modules are loaded? Do the toolchains need to match, at least for amd64 and i386 TARGET_ARCH 's? For reference as an introduction to the material in llvm's 26462 . . . It appears that the normal source of platform ABI definitions are not explicit/detailed in the area and allow for incompatibilities in this area. clang and gcc made differing choices absent being constrained to match. An example (a powerpc64 context was indicated): struct A16 { char val[16]; };=20 _Atomic struct A16 a16;=20 // GCC: _Static_assert(_Alignof(a16) =3D=3D 16, "");=20 // Clang: _Static_assert(_Alignof(a16) =3D=3D 1, "");=20 Non-power-of-2 is a general problem (not a powerpc64 context from what I can tell): struct A3 { char val[3]; }; _Atomic struct A3 a3; // GCC: _Static_assert(sizeof(a3) =3D=3D 3, ""); _Static_assert(_Alignof(a3) =3D=3D 1, ""); // Clang: _Static_assert(sizeof(a3) =3D=3D 4, ""); _Static_assert(_Alignof(a3) =3D=3D 4, ""); Comment 6 (by John McCall) is relevant: QUOTE Anyway, while I prefer the Clang rule, the GCC rule is defensible, as = are any number of other rules. The important point, however, is that = having this discussion is not the right approach to solving this = problem. The layout of _Atomic(T) is ABI. ABI rules are not generally = determined by compiler implementors making things up as they go along, = or at least they shouldn't be. The Darwin ABI for _Atomic is the rule = implemented in Clang, which we actually did think about carefully when = we adopted it. Other platforms need to make their own call, and it = probably shouldn't just be "whatever's implemented in GCC", especially = on other platforms where GCC is not the system compiler. END QUOTE =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)