FreeBSD source tree https://cgit-dev.freebsd.org/src-test/atom?h=main 2019-12-20T19:53:05Z 2019-12-20T19:53:05Z Dimitry Andric dim@FreeBSD.org 2019-12-20T19:53:05Z urn:sha1:0b57cec536236d46e3dba9bd041533462f33dbb7 This uses the new layout of the upstream repository, which was recently migrated to GitHub, and converted into a "monorepo". That is, most of the earlier separate sub-projects with their own branches and tags were consolidated into one top-level directory, and are now branched and tagged together. Updating the vendor area to match this layout is next. 2019-09-19T19:42:59Z Dimitry Andric dim@FreeBSD.org 2019-09-19T19:42:59Z urn:sha1:7dfde55afda21dc7a88c5e23e69e84b16edf51a4 Add -m(no)-spe to clang Summary: r337347 added support for the Signal Processing Engine (SPE) to LLVM. This follows that up with the clang side. This adds -mspe and -mno-spe, to match GCC. Subscribers: nemanjai, kbarton, cfe-commits Differential Revision: https://reviews.llvm.org/D49754 2019-09-19T19:25:01Z Dimitry Andric dim@FreeBSD.org 2019-09-19T19:25:01Z urn:sha1:7fc776a8270c3bdd4162f6bb32da781177731043 release 9.0.0 r372316, and update version numbers. 2019-09-02T17:32:57Z Dimitry Andric dim@FreeBSD.org 2019-09-02T17:32:57Z urn:sha1:22f75ae73839a40863eed5879bd28ee473766e6d release_90 branch r369369, and update version numbers. 2019-08-21T19:57:54Z Dimitry Andric dim@FreeBSD.org 2019-08-21T19:57:54Z urn:sha1:e123fc8fd8677e4dc86f274cffd069e5d56f4a01 2019-07-06T18:02:29Z Dimitry Andric dim@FreeBSD.org 2019-07-06T18:02:29Z urn:sha1:ec38f4f94172c28a08f6e42848552082a49de13d libunwind and openmp to the upstream release_80 branch r364487 (effectively, 8.0.1 rc3). The 8.0.1 release will most likely have no further changes. MFC after: 1 week X-MFC-With: r349004 2019-06-12T21:10:37Z Dimitry Andric dim@FreeBSD.org 2019-06-12T21:10:37Z urn:sha1:efc5c4420a710bc3e07502d32d105ddf37f44d7b libunwind and openmp to the upstream release_80 branch r363030 (effectively, 8.0.1 rc2). The 8.0.1 release should follow this within a week or so. MFC after: 2 weeks 2019-04-02T17:51:28Z Dimitry Andric dim@FreeBSD.org 2019-04-02T17:51:28Z urn:sha1:d705ee60a29efec758001781f664dec656e8239e [objc-gnustep] Use .init_array not .ctors when requested. This doesn't make a difference most of the time but FreeBSD/ARM doesn't run anything in the .ctors array. This should help with updating the libobjc2 port for armv7. Requested by: theraven Upstream PR: https://github.com/gnustep/libobjc2/issues/83 MFC after: 3 days 2019-03-07T19:33:39Z Dimitry Andric dim@FreeBSD.org 2019-03-07T19:33:39Z urn:sha1:5d3c30e56c31ebf5524c692099be3b0d890226cc Fix inline assembler constraint validation The current constraint logic is both too lax and too strict. It fails for input outside the [INT_MIN..INT_MAX] range, but it also implicitly accepts 0 as value when it should not. Adjust logic to handle both correctly. Differential Revision: https://reviews.llvm.org/D58649 Pull in r355491 from upstream clang trunk (by Hans Wennborg): Inline asm constraints: allow ICE-like pointers for the "n" constraint (PR40890) Apparently GCC allows this, and there's code relying on it (see bug). The idea is to allow expression that would have been allowed if they were cast to int. So I based the code on how such a cast would be done (the CK_PointerToIntegral case in IntExprEvaluator::VisitCastExpr()). Differential Revision: https://reviews.llvm.org/D58821 These should fix assertions and errors when using the inline assembly "n" constraint in certain ways. In case of devel/valgrind, a pointer was used as the input for the constraint, which lead to "Assertion failed: (isInt() && "Invalid accessor"), function getInt". In case of math/secp256k1, a very large integer value was used as input for the constraint, which lead to "error: value '4624529908474429119' out of range for constraint 'n'". PR: 236216, 236194 MFC after: 1 month X-MFC-With: r344779 2019-02-25T19:17:20Z Dimitry Andric dim@FreeBSD.org 2019-02-25T19:17:20Z urn:sha1:da18572fa1dc1fa7abae9e9efb1c2c3f768907a1 r354799, resolve conflicts, and bump version numbers.