WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/gnu/llvm/clang/lib?h=master 2021-02-06T21:40:59Z 2021-02-06T21:40:59Z naddy naddy@openbsd.org 2021-02-06T21:40:59Z urn:sha1:87a29e4d936af7487433ca562688be21bb3a65cb Common variables will be flagged as errors by default. This can be overridden with -fcommon. Cherry-pick this change that will be part of LLVM11. We bring it forward so we can finish fixing the fallout in the ports tree. ok deraadt@ sthen@ mglocker@ 2020-12-01T13:30:13Z visa visa@openbsd.org 2020-12-01T13:30:13Z urn:sha1:e73ff4e669dda94395f3f3df1c98f51838c775d0 This adapts the -mfix-loongson2f-btb workaround from as(1) to LLVM/clang. Because LLVM emits machine code directly without using assembly as intermediary form, the workaround has to be applied in the compiler backend in addition to the integrated assembler. Discussed with miod@ OK mortimer@ 2020-11-20T05:07:27Z gkoehler gkoehler@openbsd.org 2020-11-20T05:07:27Z urn:sha1:c968ca6e72d6d1fa752fc20e33147592b1f8103b In the PPC32 SVR4 ABI, a va_list has copies of registers from the function call. va_arg looked in the wrong registers for (the pointer representation of) an object in Objective-C, and for some types in C++. Fix va_arg to look in the general-purpose registers, not the floating-point registers. Also fix va_arg for some C++ types, like a member function pointer, that are aggregates for the ABI. Anthony Richardby found the problem in Objective-C. Eli Friedman suggested part of this fix. Fixes https://bugs.llvm.org/show_bug.cgi?id=47921 I have submitted this diff as https://reviews.llvm.org/D90329 ok kettenis@ 2020-10-12T14:52:08Z mortimer mortimer@openbsd.org 2020-10-12T14:52:08Z urn:sha1:e836804d54a63f0716bc1d6fcada314151129a64 ok deraadt@ kettenis@ 2020-09-10T20:28:13Z gkoehler gkoehler@openbsd.org 2020-09-10T20:28:13Z urn:sha1:c090f2041eb492fe987c78c48e798d9bc57c5191 Disable options like clang -fno-unsafe-math-optimizations for all targets except X86 (and SystemZ). This prevents a crash of clang, reported by cwen@, in graphics/babl or emulators/mednafen for powerpc. ok mortimer@ This change comes from llvm 11.x: https://github.com/llvm/llvm-project/commit/d4ce862 Reland "[FPEnv][Clang][Driver] Disable constrained floating point on targets lacking support." We currently have strict floating point/constrained floating point enabled for all targets. Constrained SDAG nodes get converted to the regular ones before reaching the target layer. In theory this should be fine. However, the changes are exposed to users through multiple clang options already in use in the field, and the changes are _completely_ _untested_ on almost all of our targets. Bugs have already been found, like "https://bugs.llvm.org/show_bug.cgi?id=45274". This patch disables constrained floating point options in clang everywhere except X86 and SystemZ. A warning will be printed when this happens. Use the new -fexperimental-strict-floating-point flag to force allowing strict floating point on hosts that aren't already marked as supporting it (X86 and SystemZ). Differential Revision: https://reviews.llvm.org/D80952 2020-08-09T15:55:49Z patrick patrick@openbsd.org 2020-08-09T15:55:49Z urn:sha1:30215e59641831a8d178a9975d6a345d0ec9e4da 2020-08-09T15:51:07Z patrick patrick@openbsd.org 2020-08-09T15:51:07Z urn:sha1:389bb291c0c8961ca40ac7a2636e1ca69ca7653c 2020-08-07T02:43:02Z jsg jsg@openbsd.org 2020-08-07T02:43:02Z urn:sha1:197cfd865e92f3775d0875026cda0a928e40f30c llvm 9 and later take more care not to inline cmpxchg8b/cx8 with -march=i486 instead calling __atomic_* functions. This in turn breaks the build of a large number of ports. To avoid having to add a lock or conditionally building individual ports with -march=i586 change the default so 64 bit atomics will always be available. ok patrick@ sthen@ deraadt@ 2020-08-03T14:31:31Z patrick patrick@openbsd.org 2020-08-03T14:31:31Z urn:sha1:e5dd70708596ae51455a0ffa086a00c5b29f8583 ok hackroom tested by plenty