Bug 236062
| Summary: | [exp-run] Against projects/clang800-import branch | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Dimitry Andric <dim> |
| Component: | Ports Framework | Assignee: | Port Management Team <portmgr> |
| Status: | Closed FIXED | ||
| Severity: | Affects Many People | CC: | emaste, equilibrium556, jbeich, mpysw, ports-bugs, shawn.webb, zeising |
| Priority: | --- | Flags: | antoine:
exp-run?
|
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
| Bug Depends on: | 236061, 236141, 236192, 236193, 236194, 236205, 236206, 236207, 236209, 236210, 236211, 236212, 236213, 236214, 236215, 236216, 236217, 236313, 236326, 236566, 236567, 236568, 236581, 236582, 237975, 238082 | ||
| Bug Blocks: | 236907, 240629 | ||
|
Description
Dimitry Andric
2019-02-26 18:56:16 UTC
Note that the fix from bug 236061 ("devel/json-cpp: Fix build with libc++ 8.0") should also be applied to the ports tree, as otherwise CMake and a whole bunch of other dependencies will not be built. There might be more such fallout, which is due to the new standard C++ <version> header. New failures on amd64:
+ {"origin"=>"audio/skype-call-recorder", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"biology/bedtools", "phase"=>"build", "errortype"=>"clang"}
+ {"origin"=>"databases/cockroach", "phase"=>"build", "errortype"=>"clang_werror"}
+ {"origin"=>"databases/mysql++3", "phase"=>"build", "errortype"=>"clang"}
+ {"origin"=>"databases/rocksdb", "phase"=>"build", "errortype"=>"perl"}
+ {"origin"=>"databases/rocksdb-lite", "phase"=>"build", "errortype"=>"perl"}
+ {"origin"=>"devel/catch", "phase"=>"build", "errortype"=>"clang_werror"}
+ {"origin"=>"devel/gzstream", "phase"=>"build", "errortype"=>"clang"}
+ {"origin"=>"devel/libcutl", "phase"=>"build", "errortype"=>"clang"}
+ {"origin"=>"devel/llvm40", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"devel/mdb", "phase"=>"build", "errortype"=>"clang"}
+ {"origin"=>"devel/rapidjson", "phase"=>"build", "errortype"=>"clang_werror"}
+ {"origin"=>"devel/simgear", "phase"=>"build", "errortype"=>"clang"}
+ {"origin"=>"devel/valgrind", "phase"=>"build", "errortype"=>"coredump"}
+ {"origin"=>"devel/valgrind-devel", "phase"=>"build", "errortype"=>"coredump"}
+ {"origin"=>"games/gtkradiant", "phase"=>"build", "errortype"=>"clang"}
+ {"origin"=>"games/widelands", "phase"=>"build", "errortype"=>"clang_werror"}
+ {"origin"=>"graphics/dspdfviewer", "phase"=>"build", "errortype"=>"clang_werror"}
+ {"origin"=>"graphics/goxel", "phase"=>"build", "errortype"=>"clang_werror"}
+ {"origin"=>"irc/anope", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"mail/notmuch", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"math/gap", "phase"=>"build", "errortype"=>"clang"}
+ {"origin"=>"math/secp256k1", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"math/tblis", "phase"=>"build", "errortype"=>"clang"}
+ {"origin"=>"multimedia/zoneminder", "phase"=>"build", "errortype"=>"clang"}
+ {"origin"=>"net-im/psi", "phase"=>"build", "errortype"=>"clang"}
+ {"origin"=>"net-p2p/bitcoin", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"net-p2p/bitcoin-daemon", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"net-p2p/bitcoin-utils", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"net-p2p/litecoin", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"net-p2p/litecoin-daemon", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"net-p2p/litecoin-utils", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"net-p2p/namecoin", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"net-p2p/namecoin-daemon", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"net-p2p/namecoin-utils", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"net-p2p/qtum", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"net-p2p/torrent-file-editor", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"net/ceph13", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"net/freeswitch", "phase"=>"build", "errortype"=>"clang_werror"}
+ {"origin"=>"science/hypre", "phase"=>"build", "errortype"=>"bad_C++_code"}
+ {"origin"=>"sysutils/gsmartcontrol", "phase"=>"build", "errortype"=>"clang"}
+ {"origin"=>"textproc/groonga", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"textproc/htmldoc", "phase"=>"build/runaway", "errortype"=>"runaway_process"}
+ {"origin"=>"www/palemoon", "phase"=>"stage", "errortype"=>"???"}
+ {"origin"=>"www/seamonkey", "phase"=>"stage", "errortype"=>"clang"}
+ {"origin"=>"www/squid", "phase"=>"build", "errortype"=>"clang_werror"}
+ {"origin"=>"www/squid-devel", "phase"=>"build", "errortype"=>"clang_werror"}
+ {"origin"=>"x11/polybar", "phase"=>"build", "errortype"=>"???"}
New failure logs on amd64:
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/skype-call-recorder-0.11.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/bedtools-2.27.1_2.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/cockroach-2.0.6.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/mysql++-mysql56-3.2.2.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/rocksdb-5.17.2_1.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/rocksdb-lite-5.17.2_1.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/catch-2.6.1.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/gzstream-1.5_2.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/libcutl-1.10.0_13.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/llvm40-4.0.1_12.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/mdb-0.3_1.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/rapidjson-1.1.0_5.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/simgear-2018.3.2.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/valgrind-3.10.1.20160113_7,1.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/valgrind-devel-3.10.1.20160113_6,1.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/gtkradiant-1.5.0_15.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/widelands-b19_16.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/dspdfviewer-1.15.1_11.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/goxel-0.8.2.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/anope-2.0.6.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/notmuch-0.28.1.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/gap-4.8.10.20180115.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/secp256k1-0.1.20190204.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/tblis-1.1.2.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/zoneminder-1.32.3.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/psi-1.3_2.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/bitcoin-0.17.1_2.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/bitcoin-daemon-0.17.1_5.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/bitcoin-utils-0.17.1_2.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/litecoin-0.16.3_4.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/litecoin-daemon-0.16.3_4.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/litecoin-utils-0.16.3_4.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/namecoin-0.17.0_4,1.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/namecoin-daemon-0.17.0_4,1.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/namecoin-utils-0.17.0_4,1.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/qtum-0.17.2.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/torrent-file-editor-0.3.13_2.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/ceph13-13.2.1.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/freeswitch-1.8.1_2.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/hypre-2.15.1_1.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/gsmartcontrol-1.1.3_2.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/groonga-9.0.0.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/htmldoc-1.9.3.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/palemoon-27.9.4_4.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/seamonkey-2.49.4_23.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/squid-4.5.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/squid-devel-4.0.25_3.log
http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/polybar-3.3.0.log
Can you expedite landing in order to MFC to /stable/11 and /stable/12 *before* the slush? -Werror bustage with few if any blocked ports can be safely ignored for the maintainers are often at fault for keeping the flag by default. In many cases -Werror is used together with -Wall, -Wextra, -Weverything, etc. which practically asks for bustage on compiler upgrade. Once FreeBSD 12.0 reaches EOL I'd like to start lifting LLD_UNSAFE. LLD 8 would help with that e.g., bug 233740 comment 10. If C++20 is released during FreeBSD 11.3/12.1 lifetime ports may have growing pains because libc++ cannot be easily replaced. And USES=compiler better remain nop to avoid exp-run churn. (In reply to Jan Beich from comment #3) > Can you expedite landing in order to MFC to /stable/11 and /stable/12 > *before* the slush? Sure, I'm fine with that. I requested this exp-run specifically to ensure that there are no major problems with ports. And indeed, the number of failures seems to be quite low, and most are easy to fix (if a bit cumbersome). > -Werror bustage with few if any blocked ports can be safely ignored for the > maintainers are often at fault for keeping the flag by default. In many > cases -Werror is used together with -Wall, -Wextra, -Weverything, etc. which > practically asks for bustage on compiler upgrade. Yup, let's suppress those warnings, unless they are trivial to fix. > Once FreeBSD 12.0 reaches EOL I'd like to start lifting LLD_UNSAFE. LLD 8 > would help with that e.g., bug 233740 comment 10. > > If C++20 is released during FreeBSD 11.3/12.1 lifetime ports may have > growing pains because libc++ cannot be easily replaced. And USES=compiler > better remain nop to avoid exp-run churn. The C++20 support in libc++ 8.0 is obviously not 100% finished either, but it's pretty OK for at least some time. Thanks for all of those PRs (and changes) jbeich. I agree I'd prefer to see this merged sooner rather than later - in general as long as new fail+skipped is on the order of a percent or so of the ports tree I think we're better served by merging changes like this and then addressing the fallout. One other comment, do we have a good way to get these changes (or at least reports) to the upstream project communities? (In reply to Ed Maste from comment #5) > One other comment, do we have a good way to get these changes (or at > least reports) to the upstream project communities? Bug 236192 is full of hacks. Before upstreaming more people need to dogfood libc++ 8. Proper fixes are likely to be invasive e.g., "version" file used in many places, sloppy <...> vs. "..." usage and stalled (inactive upstream). However, even with easy -Werror fixes upstreaming is a time-consuming process as it requires engaging in whatever flavor of the day bugtracker, workflow, codestyle, contributor agreement, etc. they use. Port maintainers are better positioned to accomplish that than random ports/ committers which may quickly burn out. For one, I'm already busy preparing for Boost 1.70 (bug 235956) and ICU 64 to care about upstreaming for ports that I don't even use. (In reply to Jan Beich from comment #6) > For one, I'm already busy preparing for Boost 1.70 (bug 235956) and ICU 64 to > care about upstreaming for ports that I don't even use. Indeed, I don't mean to imply I think or wish you should take on the task of upstreaming "proper" fixes for Clang/libc++ 8. Maintainers are in the best position to act as the liaison between the FreeBSD project (and our tool chain) and upstream, but I don't know that we do a good job of advocating for that today. Exp-run is still not complete on i386, there are regressions there. c++ hangs here, 115 ports skipped: http://package18.nyi.freebsd.org/data/headi386PR236062-default/2019-03-02_21h45m25s/logs/errors/opencollada-1.6.68_1.log qt5-webengine fails to build, 69 ports skipped: http://package18.nyi.freebsd.org/data/headi386PR236062-default/2019-03-02_21h45m25s/logs/errors/qt5-webengine-5.9.5_15.log (In reply to Antoine Brodin from comment #8) > qt5-webengine fails to build, 69 ports skipped: Can probably be fixed by https://chromium-review.googlesource.com/c/chromium/src/+/1473617 New failures on i386:
+ {"origin"=>"databases/mroonga", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"databases/rocksdb", "phase"=>"build", "errortype"=>"perl"}
+ {"origin"=>"databases/rocksdb-lite", "phase"=>"build", "errortype"=>"perl"}
+ {"origin"=>"devel/llvm40", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"devel/rapidjson", "phase"=>"build", "errortype"=>"clang_werror"}
+ {"origin"=>"devel/valgrind", "phase"=>"build", "errortype"=>"coredump"}
+ {"origin"=>"devel/valgrind-devel", "phase"=>"build", "errortype"=>"coredump"}
+ {"origin"=>"devel/xsd", "phase"=>"build", "errortype"=>"clang"}
+ {"origin"=>"games/flightgear", "phase"=>"build", "errortype"=>"clang"}
+ {"origin"=>"games/widelands", "phase"=>"build", "errortype"=>"clang_werror"}
+ {"origin"=>"graphics/dspdfviewer", "phase"=>"build", "errortype"=>"clang_werror"}
+ {"origin"=>"graphics/embree", "phase"=>"build", "errortype"=>"linker_error"}
+ {"origin"=>"graphics/goxel", "phase"=>"build", "errortype"=>"clang_werror"}
+ {"origin"=>"graphics/opencollada", "phase"=>"build/runaway", "errortype"=>"runaway_process"}
+ {"origin"=>"math/reduce", "phase"=>"stage", "errortype"=>"configure_error"}
+ {"origin"=>"sysutils/zol-kmod", "phase"=>"build", "errortype"=>"clang_werror"}
+ {"origin"=>"www/iridium", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"www/qt5-webengine", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"www/squid", "phase"=>"build", "errortype"=>"clang_werror"}
+ {"origin"=>"www/squid-devel", "phase"=>"build", "errortype"=>"clang_werror"}
+ {"origin"=>"x11/polybar", "phase"=>"build", "errortype"=>"???"}
New failure logs on i386:
http://package18.nyi.freebsd.org/data/headi386PR236062-default/2019-03-04_22h33m48s/logs/errors/mroonga-9.00.log
http://package18.nyi.freebsd.org/data/headi386PR236062-default/2019-03-04_22h33m48s/logs/errors/rocksdb-5.18.3.log
http://package18.nyi.freebsd.org/data/headi386PR236062-default/2019-03-04_22h33m48s/logs/errors/rocksdb-lite-5.18.3_1.log
http://package18.nyi.freebsd.org/data/headi386PR236062-default/2019-03-04_22h33m48s/logs/errors/llvm40-4.0.1_12.log
http://package18.nyi.freebsd.org/data/headi386PR236062-default/2019-03-04_22h33m48s/logs/errors/rapidjson-1.1.0_5.log
http://package18.nyi.freebsd.org/data/headi386PR236062-default/2019-03-04_22h33m48s/logs/errors/valgrind-3.10.1.20160113_7,1.log
http://package18.nyi.freebsd.org/data/headi386PR236062-default/2019-03-04_22h33m48s/logs/errors/valgrind-devel-3.10.1.20160113_6,1.log
http://package18.nyi.freebsd.org/data/headi386PR236062-default/2019-03-04_22h33m48s/logs/errors/xsd-4.0.0_3.log
http://package18.nyi.freebsd.org/data/headi386PR236062-default/2019-03-04_22h33m48s/logs/errors/flightgear-2018.3.2.log
http://package18.nyi.freebsd.org/data/headi386PR236062-default/2019-03-04_22h33m48s/logs/errors/widelands-b19_16.log
http://package18.nyi.freebsd.org/data/headi386PR236062-default/2019-03-04_22h33m48s/logs/errors/dspdfviewer-1.15.1_11.log
http://package18.nyi.freebsd.org/data/headi386PR236062-default/2019-03-04_22h33m48s/logs/errors/embree-2.17.6.log
http://package18.nyi.freebsd.org/data/headi386PR236062-default/2019-03-04_22h33m48s/logs/errors/goxel-0.8.2.log
http://package18.nyi.freebsd.org/data/headi386PR236062-default/2019-03-04_22h33m48s/logs/errors/opencollada-1.6.68_1.log
http://package18.nyi.freebsd.org/data/headi386PR236062-default/2019-03-04_22h33m48s/logs/errors/reduce-20190120.log
http://package18.nyi.freebsd.org/data/headi386PR236062-default/2019-03-04_22h33m48s/logs/errors/zol-kmod-2019030100.log
http://package18.nyi.freebsd.org/data/headi386PR236062-default/2019-03-04_22h33m48s/logs/errors/iridium-browser-2018.5.67_8.log
http://package18.nyi.freebsd.org/data/headi386PR236062-default/2019-03-04_22h33m48s/logs/errors/qt5-webengine-5.9.5_15.log
http://package18.nyi.freebsd.org/data/headi386PR236062-default/2019-03-04_22h33m48s/logs/errors/squid-4.6.log
http://package18.nyi.freebsd.org/data/headi386PR236062-default/2019-03-04_22h33m48s/logs/errors/squid-devel-4.0.25_3.log
http://package18.nyi.freebsd.org/data/headi386PR236062-default/2019-03-04_22h33m48s/logs/errors/polybar-3.3.0.log
Around 200 ports newly skipped (mostly graphics/opencollada and www/qt5-webengine)
A commit references this bug: Author: dim Date: Sat Mar 9 00:27:52 UTC 2019 New revision: 344951 URL: https://svnweb.freebsd.org/changeset/base/344951 Log: Merge llvm, clang, compiler-rt, libc++, lld, and lldb release_80 branch r355677 (effectively, 8.0.0 rc4), resolve conflicts, and bump version numbers. PR: 236062 MFC after: 1 month X-MFC-With: r344779 Changes: _U head/contrib/compiler-rt/ _U head/contrib/compiler-rt/lib/fuzzer/ _U head/contrib/libc++/ _U head/contrib/llvm/ head/contrib/llvm/include/llvm/IR/IntrinsicsX86.td _U head/contrib/llvm/tools/clang/ head/contrib/llvm/tools/clang/include/clang/Driver/CLCompatOptions.td _U head/contrib/llvm/tools/lld/ _U head/contrib/llvm/tools/lldb/ head/lib/clang/include/clang/Basic/Version.inc head/lib/clang/include/lld/Common/Version.inc head/lib/clang/include/llvm/Support/VCSRevision.h A commit references this bug: Author: dim Date: Mon Mar 11 18:45:38 UTC 2019 New revision: 345018 URL: https://svnweb.freebsd.org/changeset/base/345018 Log: Merge LLVM libunwind trunk r351319, from just before upstream's release_80 branch point. Afterwards, we will merge the rest of the changes in the actual release_80 branch. PR: 236062 MFC after: 1 month X-MFC-With: r344779 Changes: _U head/contrib/llvm/projects/libunwind/ head/contrib/llvm/projects/libunwind/LICENSE.TXT head/contrib/llvm/projects/libunwind/include/__libunwind_config.h head/contrib/llvm/projects/libunwind/include/libunwind.h head/contrib/llvm/projects/libunwind/include/mach-o/compact_unwind_encoding.h head/contrib/llvm/projects/libunwind/include/unwind.h head/contrib/llvm/projects/libunwind/src/AddressSpace.hpp head/contrib/llvm/projects/libunwind/src/CompactUnwinder.hpp head/contrib/llvm/projects/libunwind/src/DwarfInstructions.hpp head/contrib/llvm/projects/libunwind/src/DwarfParser.hpp head/contrib/llvm/projects/libunwind/src/EHHeaderParser.hpp head/contrib/llvm/projects/libunwind/src/RWMutex.hpp head/contrib/llvm/projects/libunwind/src/Registers.hpp head/contrib/llvm/projects/libunwind/src/Unwind-EHABI.cpp head/contrib/llvm/projects/libunwind/src/Unwind-EHABI.h head/contrib/llvm/projects/libunwind/src/Unwind-seh.cpp head/contrib/llvm/projects/libunwind/src/Unwind-sjlj.c head/contrib/llvm/projects/libunwind/src/UnwindCursor.hpp head/contrib/llvm/projects/libunwind/src/UnwindLevel1-gcc-ext.c head/contrib/llvm/projects/libunwind/src/UnwindLevel1.c head/contrib/llvm/projects/libunwind/src/UnwindRegistersRestore.S head/contrib/llvm/projects/libunwind/src/UnwindRegistersSave.S head/contrib/llvm/projects/libunwind/src/Unwind_AppleExtras.cpp head/contrib/llvm/projects/libunwind/src/assembly.h head/contrib/llvm/projects/libunwind/src/config.h head/contrib/llvm/projects/libunwind/src/dwarf2.h head/contrib/llvm/projects/libunwind/src/libunwind.cpp head/contrib/llvm/projects/libunwind/src/libunwind_ext.h head/contrib/llvm/projects/libunwind/src/unwind_ext.h A commit references this bug: Author: dim Date: Mon Mar 11 18:56:05 UTC 2019 New revision: 345019 URL: https://svnweb.freebsd.org/changeset/base/345019 Log: Merge LLVM libunwind release_80 branch r355677 (effectively, 8.0.0 rc4). PR: 236062 MFC after: 1 month X-MFC-With: r344779 Changes: _U head/contrib/llvm/projects/libunwind/ head/contrib/llvm/projects/libunwind/src/AddressSpace.hpp head/contrib/llvm/projects/libunwind/src/EHHeaderParser.hpp A commit references this bug: Author: dim Date: Tue Mar 12 18:19:45 UTC 2019 New revision: 345073 URL: https://svnweb.freebsd.org/changeset/base/345073 Log: Revert r308867 (which was originally committed in the clang390-import project branch): Work around LLVM PR30879, which is about a bad interaction between X86 Call Frame Optimization on i386 and libunwind, by disallowing the optimization for i386-freebsd12. This should fix some instances of broken exception handling when frame pointers are omitted, in particular some unittests run during the build of editors/libreoffice. This hack will be removed as soon as upstream has implemented a more permanent fix for this problem. And indeed, after r345018 and r345019, which updated LLVM libunwind to the most recent version, the above workaround is no longer needed. The upstream commit which fixed this is: https://llvm.org/viewvc/llvm-project?view=revision&revision=292723 Specifically, 32 bit (i386-freebsd) executables optimized with omitted frame pointers and Call Frame Optimization should now behave correctly when a C++ exception is thrown, and the stack is unwound. Upstream PR: https://llvm.org/bugs/show_bug.cgi?id=30879 PR: 236062 MFC after: 1 month X-MFC-With: r344779 Changes: _U head/ _U head/contrib/llvm/ head/contrib/llvm/lib/Target/X86/X86CallFrameOptimization.cpp A commit references this bug: Author: dim Date: Thu Mar 14 19:52:13 UTC 2019 New revision: 345152 URL: https://svnweb.freebsd.org/changeset/base/345152 Log: Merge llvm, clang, compiler-rt, libc++, libunwind, lld, and lldb release_80 branch r356034 (effectively, 8.0.0 rc5), resolve conflicts, and bump version numbers. PR: 236062 MFC after: 1 month X-MFC-With: r344779 Changes: _U head/contrib/compiler-rt/ _U head/contrib/libc++/ _U head/contrib/libunwind/ _U head/contrib/llvm/ _U head/contrib/llvm/tools/clang/ head/contrib/llvm/tools/clang/lib/AST/ExprConstant.cpp _U head/contrib/llvm/tools/lld/ _U head/contrib/llvm/tools/lldb/ head/lib/clang/include/clang/Basic/Version.inc head/lib/clang/include/lld/Common/Version.inc head/lib/clang/include/llvm/Support/VCSRevision.h A commit references this bug: Author: dim Date: Sat Mar 16 13:40:27 UTC 2019 New revision: 345231 URL: https://svnweb.freebsd.org/changeset/base/345231 Log: Add LLVM openmp trunk r351319 (just before the release_80 branch point) to contrib/llvm. This is not yet connected to the build, the glue for that will come in a follow-up commit. PR: 236062 MFC after: 1 month X-MFC-With: r344779 Changes: head/contrib/openmp/ A commit references this bug: Author: dim Date: Sat Mar 16 13:42:01 UTC 2019 New revision: 345232 URL: https://svnweb.freebsd.org/changeset/base/345232 Log: Bootstrap svn:mergeinfo on contrib/openmp. PR: 236062 MFC after: 1 month X-MFC-With: r344779 Changes: _U head/contrib/openmp/ A commit references this bug: Author: dim Date: Sat Mar 16 13:43:07 UTC 2019 New revision: 345233 URL: https://svnweb.freebsd.org/changeset/base/345233 Log: Merge openmp release_80 branch r356034 (effectively, 8.0.0 rc5). PR: 236062 MFC after: 1 month X-MFC-With: r344779 Changes: _U head/contrib/openmp/ head/contrib/openmp/runtime/src/ompt-general.cpp A commit references this bug: Author: dim Date: Sat Mar 16 13:45:14 UTC 2019 New revision: 345234 URL: https://svnweb.freebsd.org/changeset/base/345234 Log: Add openmp __kmp_gettid() wrapper, using pthread_getthreadid_np(3). This has also been submitted upstream. PR: 236062 MFC after: 1 month X-MFC-With: r344779 Changes: head/contrib/openmp/runtime/src/kmp_wrapper_getpid.h A commit references this bug: Author: dim Date: Sat Mar 16 15:01:37 UTC 2019 New revision: 345235 URL: https://svnweb.freebsd.org/changeset/base/345235 Log: Add lib/libomp, with a Makefile, and generated configuration headers. Not connected to the main build yet, as there is still the issue of the GNU omp.h header conflicting with the LLVM one. (That is, if MK_GCC is enabled.) PR: 236062 MFC after: 1 month X-MFC-With: r344779 Changes: head/lib/libomp/ head/lib/libomp/Makefile head/lib/libomp/kmp_config.h head/lib/libomp/kmp_i18n_default.inc head/lib/libomp/kmp_i18n_id.inc head/lib/libomp/omp-tools.h head/lib/libomp/omp.h A commit references this bug: Author: dim Date: Sat Mar 16 15:45:17 UTC 2019 New revision: 345236 URL: https://svnweb.freebsd.org/changeset/base/345236 Log: Connect lib/libomp to the build. * Set MK_OPENMP to yes by default only on amd64, for now. * Bump __FreeBSD_version to signal this addition. * Ensure gcc's conflicting omp.h is not installed if MK_OPENMP is yes. * Update OptionalObsoleteFiles.inc to cope with the conflicting omp.h. * Regenerate src.conf(5) with new WITH/WITHOUT fragments. Relnotes: yes PR: 236062 MFC after: 1 month X-MFC-With: r344779 Changes: head/gnu/lib/Makefile head/lib/Makefile head/share/man/man5/src.conf.5 head/share/mk/src.opts.mk head/sys/sys/param.h head/tools/build/mk/OptionalObsoleteFiles.inc head/tools/build/options/WITHOUT_OPENMP head/tools/build/options/WITH_OPENMP A commit references this bug: Author: dim Date: Sat Mar 16 17:55:23 UTC 2019 New revision: 345237 URL: https://svnweb.freebsd.org/changeset/base/345237 Log: Disable lib/libomp build for the 32-bit part of amd64 buildworld, as it is not supported for that target. Reported by: Michael Butler <imb@protected-networks.net> PR: 236062 MFC after: 1 month X-MFC-With: r344779 Changes: head/lib/Makefile A commit references this bug: Author: dim Date: Sun Mar 17 11:27:27 UTC 2019 New revision: 345242 URL: https://svnweb.freebsd.org/changeset/base/345242 Log: Explicitly link libomp.so against -lpthread, as it depends on pthread functionality. This should make example OpenMP programs work out of the box. Reported by: jbeich PR: 236062, 236581 MFC after: 1 month X-MFC-With: r344779 Changes: head/lib/libomp/Makefile A commit references this bug: Author: dim Date: Mon Mar 18 19:11:12 UTC 2019 New revision: 345278 URL: https://svnweb.freebsd.org/changeset/base/345278 Log: Also explicitly link libomp.so against -lm, as it transitively depends on scalbn and a few other math functions, via libcompiler-rt. This should allow OpenMP programs to link with BFD linkers too. Reported by: jbeich PR: 236062, 236581 MFC after: 1 month X-MFC-With: r344779 Changes: head/lib/libomp/Makefile A commit references this bug: Author: dim Date: Mon Mar 18 19:56:00 UTC 2019 New revision: 345282 URL: https://svnweb.freebsd.org/changeset/base/345282 Log: Remove --as-needed from the linker flags for libomp.so, as these actually prevent the transitive dependency on libm. Reported by: jbeich PR: 236062, 236581 MFC after: 1 month X-MFC-With: r344779 Changes: head/lib/libomp/Makefile A commit references this bug: Author: dim Date: Mon Mar 18 21:04:29 UTC 2019 New revision: 345283 URL: https://svnweb.freebsd.org/changeset/base/345283 Log: Enable building libomp.so for 32-bit x86. This is done by selectively enabling the functions that save and restore MXCSR, since access to this register requires SSE support. Note that you may run into other issues with OpenMP on i386, since this *not* yet supported upstream, and certainly not extensively tested. PR: 236062, 236582 MFC after: 1 month X-MFC-With: r344779 Changes: head/contrib/openmp/runtime/src/kmp.h head/contrib/openmp/runtime/src/kmp_runtime.cpp head/lib/Makefile A commit references this bug: Author: dim Date: Tue Mar 19 06:58:28 UTC 2019 New revision: 345291 URL: https://svnweb.freebsd.org/changeset/base/345291 Log: Turn on MK_OPENMP for i386 by default, now that it can build. Noticed by: jbeich PR: 236062, 236582 MFC after: 1 month X-MFC-With: r344779 Changes: head/share/mk/src.opts.mk A commit references this bug: Author: dim Date: Wed Mar 20 19:18:28 UTC 2019 New revision: 345345 URL: https://svnweb.freebsd.org/changeset/base/345345 Log: Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 8.0.0 final release r356365. There were no functional changes since the most recent merge, of 8.0.0 rc5. Release notes for llvm, clang, lld and libc++ 8.0.0 are now available: https://llvm.org/releases/8.0.0/docs/ReleaseNotes.html https://llvm.org/releases/8.0.0/tools/clang/docs/ReleaseNotes.html https://llvm.org/releases/8.0.0/tools/lld/docs/ReleaseNotes.html https://llvm.org/releases/8.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 236062 MFC after: 1 month X-MFC-With: r344779 Changes: _U head/contrib/compiler-rt/ _U head/contrib/libc++/ _U head/contrib/libunwind/ _U head/contrib/llvm/ _U head/contrib/llvm/tools/clang/ head/contrib/llvm/tools/clang/lib/Basic/Version.cpp _U head/contrib/llvm/tools/lld/ _U head/contrib/llvm/tools/lldb/ _U head/contrib/openmp/ head/lib/clang/include/clang/Basic/Version.inc head/lib/clang/include/lld/Common/Version.inc head/lib/clang/include/llvm/Support/VCSRevision.h A commit references this bug: Author: dim Date: Wed Mar 20 20:57:13 UTC 2019 New revision: 345349 URL: https://svnweb.freebsd.org/changeset/base/345349 Log: Pull in r352826 from upstream lld trunk (by Fangrui Song): [ELF] Support --{,no-}allow-shlib-undefined Summary: In ld.bfd/gold, --no-allow-shlib-undefined is the default when linking an executable. This patch implements a check to error on undefined symbols in a shared object, if all of its DT_NEEDED entries are seen. Our approach resembles the one used in gold, achieves a good balance to be useful but not too smart (ld.bfd traces all DSOs and emulates the behavior of a dynamic linker to catch more cases). The error is issued based on the symbol table, different from undefined reference errors issued for relocations. It is most effective when there are DSOs that were not linked with -z defs (e.g. when static sanitizers runtime is used). gold has a comment that some system libraries on GNU/Linux may have spurious undefined references and thus system libraries should be excluded (https://sourceware.org/bugzilla/show_bug.cgi?id=6811). The story may have changed now but we make --allow-shlib-undefined the default for now. Its interaction with -shared can be discussed in the future. Reviewers: ruiu, grimar, pcc, espindola Reviewed By: ruiu Subscribers: joerg, emaste, arichardson, llvm-commits Differential Revision: https://reviews.llvm.org/D57385 Pull in r352943 from upstream lld trunk (by Fangrui Song): [ELF] Default to --no-allow-shlib-undefined for executables Summary: This follows the ld.bfd/gold behavior. The error check is useful as it captures a common type of ld.so undefined symbol errors as link-time errors: // a.cc => a.so (not linked with -z defs) void f(); // f is undefined void g() { f(); } // b.cc => executable with a DT_NEEDED entry on a.so void g(); int main() { g(); } // ld.so errors when g() is executed (lazy binding) or when the program is started (-z now) // symbol lookup error: ... undefined symbol: f Reviewers: ruiu, grimar, pcc, espindola Reviewed By: ruiu Subscribers: llvm-commits, emaste, arichardson Tags: #llvm Differential Revision: https://reviews.llvm.org/D57569 Together, these add support for --no-allow-shlib-undefined, and make it the default for executables, so they will fail to link if any symbols from needed shared libraries are undefined. Reported by: jbeich PR: 236062, 236141 MFC after: 1 month X-MFC-With: r344779 Changes: head/contrib/llvm/tools/lld/ELF/Config.h head/contrib/llvm/tools/lld/ELF/Driver.cpp head/contrib/llvm/tools/lld/ELF/InputFiles.cpp head/contrib/llvm/tools/lld/ELF/InputFiles.h head/contrib/llvm/tools/lld/ELF/Options.td head/contrib/llvm/tools/lld/ELF/SymbolTable.cpp head/contrib/llvm/tools/lld/ELF/SymbolTable.h head/contrib/llvm/tools/lld/ELF/Writer.cpp head/contrib/llvm/tools/lld/docs/ld.lld.1 head/lib/clang/include/lld/Common/Version.inc There are regressions in ld between branches/release_80 356034 and tags/RELEASE_800/final 356365 Now, a lot of gnome related ports fail to link: http://gohan2.ysv.freebsd.org/data/head-amd64-default-baseline/p496395_s345355/logs/errors/libglade2-2.6.4_9.log http://gohan2.ysv.freebsd.org/data/head-amd64-default-baseline/p496395_s345355/logs/errors/gtk3-3.24.5.log http://gohan2.ysv.freebsd.org/data/head-amd64-default-baseline/p496395_s345355/logs/errors/tesseract-3.05.02_4.log http://gohan2.ysv.freebsd.org/data/head-amd64-default-baseline/p496395_s345355/logs/errors/sdl_ttf-2.0.11_7.log etc. (In reply to Antoine Brodin from comment #30) > There are regressions in ld between branches/release_80 356034 and > tags/RELEASE_800/final 356365 > > Now, a lot of gnome related ports fail to link: > > http://gohan2.ysv.freebsd.org/data/head-amd64-default-baseline/ > p496395_s345355/logs/errors/libglade2-2.6.4_9.log > http://gohan2.ysv.freebsd.org/data/head-amd64-default-baseline/ > p496395_s345355/logs/errors/gtk3-3.24.5.log > http://gohan2.ysv.freebsd.org/data/head-amd64-default-baseline/ > p496395_s345355/logs/errors/tesseract-3.05.02_4.log > http://gohan2.ysv.freebsd.org/data/head-amd64-default-baseline/ > p496395_s345355/logs/errors/sdl_ttf-2.0.11_7.log Yes, this is due to base r345349, for bug 236141. Maybe jbeich has some good ideas? :) A commit references this bug: Author: dim Date: Sat Mar 23 14:10:06 UTC 2019 New revision: 345449 URL: https://svnweb.freebsd.org/changeset/base/345449 Log: Pull in r356809 from upstream llvm trunk (by Eli Friedman): [ARM] Don't form "ands" when it isn't scheduled correctly. In r322972/r323136, the iteration here was changed to catch cases at the beginning of a basic block... but we accidentally deleted an important safety check. Restore that check to the way it was. Fixes https://bugs.llvm.org/show_bug.cgi?id=41116 Differential Revision: https://reviews.llvm.org/D59680 This should fix "Assertion failed: (LiveCPSR && "CPSR liveness tracking is wrong!"), function UpdateCPSRUse" errors when building the devel/xwpe port for armv7. PR: 236062, 236568 MFC after: 1 month X-MFC-With: r344779 Changes: head/contrib/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp A commit references this bug: Author: dim Date: Wed Apr 17 20:08:03 UTC 2019 New revision: 346331 URL: https://svnweb.freebsd.org/changeset/base/346331 Log: After r346168, also merge build infrastructure for LLVM libomp. MFC r345235: Add lib/libomp, with a Makefile, and generated configuration headers. Not connected to the main build yet, as there is still the issue of the GNU omp.h header conflicting with the LLVM one. (That is, if MK_GCC is enabled.) PR: 236062 MFC r345236: Connect lib/libomp to the build. * Set MK_OPENMP to yes by default only on amd64, for now. * Bump __FreeBSD_version to signal this addition. * Ensure gcc's conflicting omp.h is not installed if MK_OPENMP is yes. * Update OptionalObsoleteFiles.inc to cope with the conflicting omp.h. * Regenerate src.conf(5) with new WITH/WITHOUT fragments. Relnotes: yes PR: 236062 MFC r345242: Explicitly link libomp.so against -lpthread, as it depends on pthread functionality. This should make example OpenMP programs work out of the box. Reported by: jbeich PR: 236062, 236581 MFC r345278: Also explicitly link libomp.so against -lm, as it transitively depends on scalbn and a few other math functions, via libcompiler-rt. This should allow OpenMP programs to link with BFD linkers too. Reported by: jbeich PR: 236062, 236581 MFC r345282: Remove --as-needed from the linker flags for libomp.so, as these actually prevent the transitive dependency on libm. Reported by: jbeich PR: 236062, 236581 MFC r345291: Turn on MK_OPENMP for i386 by default, now that it can build. Noticed by: jbeich PR: 236062, 236582 Changes: _U stable/12/ stable/12/gnu/lib/Makefile stable/12/lib/libomp/ stable/12/lib/libomp/Makefile stable/12/share/man/man5/src.conf.5 stable/12/share/mk/src.opts.mk stable/12/tools/build/mk/OptionalObsoleteFiles.inc stable/12/tools/build/options/WITHOUT_OPENMP stable/12/tools/build/options/WITH_OPENMP A commit references this bug: Author: dim Date: Wed Apr 17 20:08:03 UTC 2019 New revision: 346331 URL: https://svnweb.freebsd.org/changeset/base/346331 Log: After r346168, also merge build infrastructure for LLVM libomp. MFC r345235: Add lib/libomp, with a Makefile, and generated configuration headers. Not connected to the main build yet, as there is still the issue of the GNU omp.h header conflicting with the LLVM one. (That is, if MK_GCC is enabled.) PR: 236062 MFC r345236: Connect lib/libomp to the build. * Set MK_OPENMP to yes by default only on amd64, for now. * Bump __FreeBSD_version to signal this addition. * Ensure gcc's conflicting omp.h is not installed if MK_OPENMP is yes. * Update OptionalObsoleteFiles.inc to cope with the conflicting omp.h. * Regenerate src.conf(5) with new WITH/WITHOUT fragments. Relnotes: yes PR: 236062 MFC r345242: Explicitly link libomp.so against -lpthread, as it depends on pthread functionality. This should make example OpenMP programs work out of the box. Reported by: jbeich PR: 236062, 236581 MFC r345278: Also explicitly link libomp.so against -lm, as it transitively depends on scalbn and a few other math functions, via libcompiler-rt. This should allow OpenMP programs to link with BFD linkers too. Reported by: jbeich PR: 236062, 236581 MFC r345282: Remove --as-needed from the linker flags for libomp.so, as these actually prevent the transitive dependency on libm. Reported by: jbeich PR: 236062, 236581 MFC r345291: Turn on MK_OPENMP for i386 by default, now that it can build. Noticed by: jbeich PR: 236062, 236582 Changes: _U stable/12/ stable/12/gnu/lib/Makefile stable/12/lib/libomp/ stable/12/lib/libomp/Makefile stable/12/share/man/man5/src.conf.5 stable/12/share/mk/src.opts.mk stable/12/tools/build/mk/OptionalObsoleteFiles.inc stable/12/tools/build/options/WITHOUT_OPENMP stable/12/tools/build/options/WITH_OPENMP A commit references this bug: Author: dim Date: Wed Apr 17 20:08:04 UTC 2019 New revision: 346331 URL: https://svnweb.freebsd.org/changeset/base/346331 Log: After r346168, also merge build infrastructure for LLVM libomp. MFC r345235: Add lib/libomp, with a Makefile, and generated configuration headers. Not connected to the main build yet, as there is still the issue of the GNU omp.h header conflicting with the LLVM one. (That is, if MK_GCC is enabled.) PR: 236062 MFC r345236: Connect lib/libomp to the build. * Set MK_OPENMP to yes by default only on amd64, for now. * Bump __FreeBSD_version to signal this addition. * Ensure gcc's conflicting omp.h is not installed if MK_OPENMP is yes. * Update OptionalObsoleteFiles.inc to cope with the conflicting omp.h. * Regenerate src.conf(5) with new WITH/WITHOUT fragments. Relnotes: yes PR: 236062 MFC r345242: Explicitly link libomp.so against -lpthread, as it depends on pthread functionality. This should make example OpenMP programs work out of the box. Reported by: jbeich PR: 236062, 236581 MFC r345278: Also explicitly link libomp.so against -lm, as it transitively depends on scalbn and a few other math functions, via libcompiler-rt. This should allow OpenMP programs to link with BFD linkers too. Reported by: jbeich PR: 236062, 236581 MFC r345282: Remove --as-needed from the linker flags for libomp.so, as these actually prevent the transitive dependency on libm. Reported by: jbeich PR: 236062, 236581 MFC r345291: Turn on MK_OPENMP for i386 by default, now that it can build. Noticed by: jbeich PR: 236062, 236582 Changes: _U stable/12/ stable/12/gnu/lib/Makefile stable/12/lib/libomp/ stable/12/lib/libomp/Makefile stable/12/share/man/man5/src.conf.5 stable/12/share/mk/src.opts.mk stable/12/tools/build/mk/OptionalObsoleteFiles.inc stable/12/tools/build/options/WITHOUT_OPENMP stable/12/tools/build/options/WITH_OPENMP A commit references this bug: Author: dim Date: Wed Apr 17 20:08:03 UTC 2019 New revision: 346331 URL: https://svnweb.freebsd.org/changeset/base/346331 Log: After r346168, also merge build infrastructure for LLVM libomp. MFC r345235: Add lib/libomp, with a Makefile, and generated configuration headers. Not connected to the main build yet, as there is still the issue of the GNU omp.h header conflicting with the LLVM one. (That is, if MK_GCC is enabled.) PR: 236062 MFC r345236: Connect lib/libomp to the build. * Set MK_OPENMP to yes by default only on amd64, for now. * Bump __FreeBSD_version to signal this addition. * Ensure gcc's conflicting omp.h is not installed if MK_OPENMP is yes. * Update OptionalObsoleteFiles.inc to cope with the conflicting omp.h. * Regenerate src.conf(5) with new WITH/WITHOUT fragments. Relnotes: yes PR: 236062 MFC r345242: Explicitly link libomp.so against -lpthread, as it depends on pthread functionality. This should make example OpenMP programs work out of the box. Reported by: jbeich PR: 236062, 236581 MFC r345278: Also explicitly link libomp.so against -lm, as it transitively depends on scalbn and a few other math functions, via libcompiler-rt. This should allow OpenMP programs to link with BFD linkers too. Reported by: jbeich PR: 236062, 236581 MFC r345282: Remove --as-needed from the linker flags for libomp.so, as these actually prevent the transitive dependency on libm. Reported by: jbeich PR: 236062, 236581 MFC r345291: Turn on MK_OPENMP for i386 by default, now that it can build. Noticed by: jbeich PR: 236062, 236582 Changes: _U stable/12/ stable/12/gnu/lib/Makefile stable/12/lib/libomp/ stable/12/lib/libomp/Makefile stable/12/share/man/man5/src.conf.5 stable/12/share/mk/src.opts.mk stable/12/tools/build/mk/OptionalObsoleteFiles.inc stable/12/tools/build/options/WITHOUT_OPENMP stable/12/tools/build/options/WITH_OPENMP A commit references this bug: Author: dim Date: Wed Apr 17 20:08:04 UTC 2019 New revision: 346331 URL: https://svnweb.freebsd.org/changeset/base/346331 Log: After r346168, also merge build infrastructure for LLVM libomp. MFC r345235: Add lib/libomp, with a Makefile, and generated configuration headers. Not connected to the main build yet, as there is still the issue of the GNU omp.h header conflicting with the LLVM one. (That is, if MK_GCC is enabled.) PR: 236062 MFC r345236: Connect lib/libomp to the build. * Set MK_OPENMP to yes by default only on amd64, for now. * Bump __FreeBSD_version to signal this addition. * Ensure gcc's conflicting omp.h is not installed if MK_OPENMP is yes. * Update OptionalObsoleteFiles.inc to cope with the conflicting omp.h. * Regenerate src.conf(5) with new WITH/WITHOUT fragments. Relnotes: yes PR: 236062 MFC r345242: Explicitly link libomp.so against -lpthread, as it depends on pthread functionality. This should make example OpenMP programs work out of the box. Reported by: jbeich PR: 236062, 236581 MFC r345278: Also explicitly link libomp.so against -lm, as it transitively depends on scalbn and a few other math functions, via libcompiler-rt. This should allow OpenMP programs to link with BFD linkers too. Reported by: jbeich PR: 236062, 236581 MFC r345282: Remove --as-needed from the linker flags for libomp.so, as these actually prevent the transitive dependency on libm. Reported by: jbeich PR: 236062, 236581 MFC r345291: Turn on MK_OPENMP for i386 by default, now that it can build. Noticed by: jbeich PR: 236062, 236582 Changes: _U stable/12/ stable/12/gnu/lib/Makefile stable/12/lib/libomp/ stable/12/lib/libomp/Makefile stable/12/share/man/man5/src.conf.5 stable/12/share/mk/src.opts.mk stable/12/tools/build/mk/OptionalObsoleteFiles.inc stable/12/tools/build/options/WITHOUT_OPENMP stable/12/tools/build/options/WITH_OPENMP A commit references this bug: Author: dim Date: Wed Apr 17 20:08:03 UTC 2019 New revision: 346331 URL: https://svnweb.freebsd.org/changeset/base/346331 Log: After r346168, also merge build infrastructure for LLVM libomp. MFC r345235: Add lib/libomp, with a Makefile, and generated configuration headers. Not connected to the main build yet, as there is still the issue of the GNU omp.h header conflicting with the LLVM one. (That is, if MK_GCC is enabled.) PR: 236062 MFC r345236: Connect lib/libomp to the build. * Set MK_OPENMP to yes by default only on amd64, for now. * Bump __FreeBSD_version to signal this addition. * Ensure gcc's conflicting omp.h is not installed if MK_OPENMP is yes. * Update OptionalObsoleteFiles.inc to cope with the conflicting omp.h. * Regenerate src.conf(5) with new WITH/WITHOUT fragments. Relnotes: yes PR: 236062 MFC r345242: Explicitly link libomp.so against -lpthread, as it depends on pthread functionality. This should make example OpenMP programs work out of the box. Reported by: jbeich PR: 236062, 236581 MFC r345278: Also explicitly link libomp.so against -lm, as it transitively depends on scalbn and a few other math functions, via libcompiler-rt. This should allow OpenMP programs to link with BFD linkers too. Reported by: jbeich PR: 236062, 236581 MFC r345282: Remove --as-needed from the linker flags for libomp.so, as these actually prevent the transitive dependency on libm. Reported by: jbeich PR: 236062, 236581 MFC r345291: Turn on MK_OPENMP for i386 by default, now that it can build. Noticed by: jbeich PR: 236062, 236582 Changes: _U stable/12/ stable/12/gnu/lib/Makefile stable/12/lib/libomp/ stable/12/lib/libomp/Makefile stable/12/share/man/man5/src.conf.5 stable/12/share/mk/src.opts.mk stable/12/tools/build/mk/OptionalObsoleteFiles.inc stable/12/tools/build/options/WITHOUT_OPENMP stable/12/tools/build/options/WITH_OPENMP A commit references this bug: Author: dim Date: Wed Apr 17 20:16:50 UTC 2019 New revision: 346333 URL: https://svnweb.freebsd.org/changeset/base/346333 Log: After r346168, also merge build infrastructure for LLVM libomp. MFC r345235: Add lib/libomp, with a Makefile, and generated configuration headers. Not connected to the main build yet, as there is still the issue of the GNU omp.h header conflicting with the LLVM one. (That is, if MK_GCC is enabled.) PR: 236062 MFC r345236: Connect lib/libomp to the build. * Set MK_OPENMP to yes by default only on amd64, for now. * Bump __FreeBSD_version to signal this addition. * Ensure gcc's conflicting omp.h is not installed if MK_OPENMP is yes. * Update OptionalObsoleteFiles.inc to cope with the conflicting omp.h. * Regenerate src.conf(5) with new WITH/WITHOUT fragments. Relnotes: yes PR: 236062 MFC r345242: Explicitly link libomp.so against -lpthread, as it depends on pthread functionality. This should make example OpenMP programs work out of the box. Reported by: jbeich PR: 236062, 236581 MFC r345278: Also explicitly link libomp.so against -lm, as it transitively depends on scalbn and a few other math functions, via libcompiler-rt. This should allow OpenMP programs to link with BFD linkers too. Reported by: jbeich PR: 236062, 236581 MFC r345282: Remove --as-needed from the linker flags for libomp.so, as these actually prevent the transitive dependency on libm. Reported by: jbeich PR: 236062, 236581 MFC r345291: Turn on MK_OPENMP for i386 by default, now that it can build. Noticed by: jbeich PR: 236062, 236582 Changes: _U stable/11/ stable/11/gnu/lib/Makefile stable/11/lib/libomp/ stable/11/lib/libomp/Makefile stable/11/share/man/man5/src.conf.5 stable/11/share/mk/src.opts.mk stable/11/tools/build/mk/OptionalObsoleteFiles.inc stable/11/tools/build/options/WITHOUT_OPENMP stable/11/tools/build/options/WITH_OPENMP A commit references this bug: Author: dim Date: Wed Apr 17 20:16:50 UTC 2019 New revision: 346333 URL: https://svnweb.freebsd.org/changeset/base/346333 Log: After r346168, also merge build infrastructure for LLVM libomp. MFC r345235: Add lib/libomp, with a Makefile, and generated configuration headers. Not connected to the main build yet, as there is still the issue of the GNU omp.h header conflicting with the LLVM one. (That is, if MK_GCC is enabled.) PR: 236062 MFC r345236: Connect lib/libomp to the build. * Set MK_OPENMP to yes by default only on amd64, for now. * Bump __FreeBSD_version to signal this addition. * Ensure gcc's conflicting omp.h is not installed if MK_OPENMP is yes. * Update OptionalObsoleteFiles.inc to cope with the conflicting omp.h. * Regenerate src.conf(5) with new WITH/WITHOUT fragments. Relnotes: yes PR: 236062 MFC r345242: Explicitly link libomp.so against -lpthread, as it depends on pthread functionality. This should make example OpenMP programs work out of the box. Reported by: jbeich PR: 236062, 236581 MFC r345278: Also explicitly link libomp.so against -lm, as it transitively depends on scalbn and a few other math functions, via libcompiler-rt. This should allow OpenMP programs to link with BFD linkers too. Reported by: jbeich PR: 236062, 236581 MFC r345282: Remove --as-needed from the linker flags for libomp.so, as these actually prevent the transitive dependency on libm. Reported by: jbeich PR: 236062, 236581 MFC r345291: Turn on MK_OPENMP for i386 by default, now that it can build. Noticed by: jbeich PR: 236062, 236582 Changes: _U stable/11/ stable/11/gnu/lib/Makefile stable/11/lib/libomp/ stable/11/lib/libomp/Makefile stable/11/share/man/man5/src.conf.5 stable/11/share/mk/src.opts.mk stable/11/tools/build/mk/OptionalObsoleteFiles.inc stable/11/tools/build/options/WITHOUT_OPENMP stable/11/tools/build/options/WITH_OPENMP A commit references this bug: Author: dim Date: Wed Apr 17 20:16:50 UTC 2019 New revision: 346333 URL: https://svnweb.freebsd.org/changeset/base/346333 Log: After r346168, also merge build infrastructure for LLVM libomp. MFC r345235: Add lib/libomp, with a Makefile, and generated configuration headers. Not connected to the main build yet, as there is still the issue of the GNU omp.h header conflicting with the LLVM one. (That is, if MK_GCC is enabled.) PR: 236062 MFC r345236: Connect lib/libomp to the build. * Set MK_OPENMP to yes by default only on amd64, for now. * Bump __FreeBSD_version to signal this addition. * Ensure gcc's conflicting omp.h is not installed if MK_OPENMP is yes. * Update OptionalObsoleteFiles.inc to cope with the conflicting omp.h. * Regenerate src.conf(5) with new WITH/WITHOUT fragments. Relnotes: yes PR: 236062 MFC r345242: Explicitly link libomp.so against -lpthread, as it depends on pthread functionality. This should make example OpenMP programs work out of the box. Reported by: jbeich PR: 236062, 236581 MFC r345278: Also explicitly link libomp.so against -lm, as it transitively depends on scalbn and a few other math functions, via libcompiler-rt. This should allow OpenMP programs to link with BFD linkers too. Reported by: jbeich PR: 236062, 236581 MFC r345282: Remove --as-needed from the linker flags for libomp.so, as these actually prevent the transitive dependency on libm. Reported by: jbeich PR: 236062, 236581 MFC r345291: Turn on MK_OPENMP for i386 by default, now that it can build. Noticed by: jbeich PR: 236062, 236582 Changes: _U stable/11/ stable/11/gnu/lib/Makefile stable/11/lib/libomp/ stable/11/lib/libomp/Makefile stable/11/share/man/man5/src.conf.5 stable/11/share/mk/src.opts.mk stable/11/tools/build/mk/OptionalObsoleteFiles.inc stable/11/tools/build/options/WITHOUT_OPENMP stable/11/tools/build/options/WITH_OPENMP A commit references this bug: Author: dim Date: Wed Apr 17 20:16:51 UTC 2019 New revision: 346333 URL: https://svnweb.freebsd.org/changeset/base/346333 Log: After r346168, also merge build infrastructure for LLVM libomp. MFC r345235: Add lib/libomp, with a Makefile, and generated configuration headers. Not connected to the main build yet, as there is still the issue of the GNU omp.h header conflicting with the LLVM one. (That is, if MK_GCC is enabled.) PR: 236062 MFC r345236: Connect lib/libomp to the build. * Set MK_OPENMP to yes by default only on amd64, for now. * Bump __FreeBSD_version to signal this addition. * Ensure gcc's conflicting omp.h is not installed if MK_OPENMP is yes. * Update OptionalObsoleteFiles.inc to cope with the conflicting omp.h. * Regenerate src.conf(5) with new WITH/WITHOUT fragments. Relnotes: yes PR: 236062 MFC r345242: Explicitly link libomp.so against -lpthread, as it depends on pthread functionality. This should make example OpenMP programs work out of the box. Reported by: jbeich PR: 236062, 236581 MFC r345278: Also explicitly link libomp.so against -lm, as it transitively depends on scalbn and a few other math functions, via libcompiler-rt. This should allow OpenMP programs to link with BFD linkers too. Reported by: jbeich PR: 236062, 236581 MFC r345282: Remove --as-needed from the linker flags for libomp.so, as these actually prevent the transitive dependency on libm. Reported by: jbeich PR: 236062, 236581 MFC r345291: Turn on MK_OPENMP for i386 by default, now that it can build. Noticed by: jbeich PR: 236062, 236582 Changes: _U stable/11/ stable/11/gnu/lib/Makefile stable/11/lib/libomp/ stable/11/lib/libomp/Makefile stable/11/share/man/man5/src.conf.5 stable/11/share/mk/src.opts.mk stable/11/tools/build/mk/OptionalObsoleteFiles.inc stable/11/tools/build/options/WITHOUT_OPENMP stable/11/tools/build/options/WITH_OPENMP A commit references this bug: Author: dim Date: Wed Apr 17 20:16:51 UTC 2019 New revision: 346333 URL: https://svnweb.freebsd.org/changeset/base/346333 Log: After r346168, also merge build infrastructure for LLVM libomp. MFC r345235: Add lib/libomp, with a Makefile, and generated configuration headers. Not connected to the main build yet, as there is still the issue of the GNU omp.h header conflicting with the LLVM one. (That is, if MK_GCC is enabled.) PR: 236062 MFC r345236: Connect lib/libomp to the build. * Set MK_OPENMP to yes by default only on amd64, for now. * Bump __FreeBSD_version to signal this addition. * Ensure gcc's conflicting omp.h is not installed if MK_OPENMP is yes. * Update OptionalObsoleteFiles.inc to cope with the conflicting omp.h. * Regenerate src.conf(5) with new WITH/WITHOUT fragments. Relnotes: yes PR: 236062 MFC r345242: Explicitly link libomp.so against -lpthread, as it depends on pthread functionality. This should make example OpenMP programs work out of the box. Reported by: jbeich PR: 236062, 236581 MFC r345278: Also explicitly link libomp.so against -lm, as it transitively depends on scalbn and a few other math functions, via libcompiler-rt. This should allow OpenMP programs to link with BFD linkers too. Reported by: jbeich PR: 236062, 236581 MFC r345282: Remove --as-needed from the linker flags for libomp.so, as these actually prevent the transitive dependency on libm. Reported by: jbeich PR: 236062, 236581 MFC r345291: Turn on MK_OPENMP for i386 by default, now that it can build. Noticed by: jbeich PR: 236062, 236582 Changes: _U stable/11/ stable/11/gnu/lib/Makefile stable/11/lib/libomp/ stable/11/lib/libomp/Makefile stable/11/share/man/man5/src.conf.5 stable/11/share/mk/src.opts.mk stable/11/tools/build/mk/OptionalObsoleteFiles.inc stable/11/tools/build/options/WITHOUT_OPENMP stable/11/tools/build/options/WITH_OPENMP A commit references this bug: Author: dim Date: Wed Apr 17 20:16:51 UTC 2019 New revision: 346333 URL: https://svnweb.freebsd.org/changeset/base/346333 Log: After r346168, also merge build infrastructure for LLVM libomp. MFC r345235: Add lib/libomp, with a Makefile, and generated configuration headers. Not connected to the main build yet, as there is still the issue of the GNU omp.h header conflicting with the LLVM one. (That is, if MK_GCC is enabled.) PR: 236062 MFC r345236: Connect lib/libomp to the build. * Set MK_OPENMP to yes by default only on amd64, for now. * Bump __FreeBSD_version to signal this addition. * Ensure gcc's conflicting omp.h is not installed if MK_OPENMP is yes. * Update OptionalObsoleteFiles.inc to cope with the conflicting omp.h. * Regenerate src.conf(5) with new WITH/WITHOUT fragments. Relnotes: yes PR: 236062 MFC r345242: Explicitly link libomp.so against -lpthread, as it depends on pthread functionality. This should make example OpenMP programs work out of the box. Reported by: jbeich PR: 236062, 236581 MFC r345278: Also explicitly link libomp.so against -lm, as it transitively depends on scalbn and a few other math functions, via libcompiler-rt. This should allow OpenMP programs to link with BFD linkers too. Reported by: jbeich PR: 236062, 236581 MFC r345282: Remove --as-needed from the linker flags for libomp.so, as these actually prevent the transitive dependency on libm. Reported by: jbeich PR: 236062, 236581 MFC r345291: Turn on MK_OPENMP for i386 by default, now that it can build. Noticed by: jbeich PR: 236062, 236582 Changes: _U stable/11/ stable/11/gnu/lib/Makefile stable/11/lib/libomp/ stable/11/lib/libomp/Makefile stable/11/share/man/man5/src.conf.5 stable/11/share/mk/src.opts.mk stable/11/tools/build/mk/OptionalObsoleteFiles.inc stable/11/tools/build/options/WITHOUT_OPENMP stable/11/tools/build/options/WITH_OPENMP Can you also MFC base r337156 (libc++fs) and maybe base r318594 (libc++experimental) to /stable/11 and /stable/12? std::filesystem is part of C++17 but /stable/11 doesn't even have libc++experimental atm. Example consumer: https://github.com/Alexays/Waybar/blob/0d0f5ed7db16/meson.build#L15-L19 Nevermind comment 45. I didn't notice base r344213. *** Bug 222858 has been marked as a duplicate of this bug. *** A commit references this bug: Author: dim Date: Sat Jul 20 15:26:22 UTC 2019 New revision: 350177 URL: https://svnweb.freebsd.org/changeset/base/350177 Log: Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 8.0.1 final release r366581. The only functional change is a fix for a mismerge of upstream r360816, which properly restores the r2 register when unwinding on PowerPC64 (See https://reviews.freebsd.org/D20337). Relnotes: yes PR: 236062 MFC after: 3 days X-MFC-With: r349004 Changes: _U head/contrib/compiler-rt/ _U head/contrib/libc++/ _U head/contrib/libunwind/ head/contrib/libunwind/src/assembly.h _U head/contrib/llvm/ _U head/contrib/llvm/tools/clang/ head/contrib/llvm/tools/clang/lib/Basic/Version.cpp _U head/contrib/llvm/tools/lld/ _U head/contrib/llvm/tools/lldb/ _U head/contrib/openmp/ head/lib/clang/include/clang/Basic/Version.inc head/lib/clang/include/lld/Common/Version.inc head/lib/clang/include/llvm/Support/VCSRevision.h A commit references this bug: Author: dim Date: Tue Jul 23 18:40:35 UTC 2019 New revision: 350256 URL: https://svnweb.freebsd.org/changeset/base/350256 Log: MFC r348504 (by kevans): llvm-symbolizer: Move out of CLANG_EXTRAS, into CLANG ASAN reports become a lot more useful with llvm-symbolizer in $PATH, and the build is not much more time-consuming. The added benefit is that the resulting reports will actually include symbol information; without, thread trace information includes a bunch of addresses that immediately resolve to an inline function in ^/contrib/compiler-rt/lib/sanitizer_common/sanitizer_common.h and take a little more effort to examine. Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D20484 MFC r349004: Upgrade our copies of clang, llvm, lld, lldb, compiler-rt, libc++, 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 r349351 (by jhibbits, partially): powerpc: Transition to Secure-PLT, like most other OSs (Toolchain part) Summary: Toolchain follow-up to r349350. LLVM patches will be submitted upstream for 9.0 as well. The bsd.cpu.mk change is required because GNU ld assumes BSS-PLT if it cannot determine for certain that it needs Secure-PLT, and some binaries do not compile in such a way to make it know to use Secure-PLT. Reviewed By: nwhitehorn, bdragon, pfg Differential Revision: https://reviews.freebsd.org/D20598 MFC r349793: Upgrade our copies of clang, llvm, lld, lldb, compiler-rt, libc++, 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 r350177: Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 8.0.1 final release r366581. The only functional change is a fix for a mismerge of upstream r360816, which properly restores the r2 register when unwinding on PowerPC64 (See https://reviews.freebsd.org/D20337). Relnotes: yes PR: 236062 Changes: _U stable/12/ stable/12/ObsoleteFiles.inc stable/12/UPDATING stable/12/contrib/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_netbsd.cc stable/12/contrib/libunwind/src/DwarfInstructions.hpp stable/12/contrib/libunwind/src/UnwindRegistersRestore.S stable/12/contrib/libunwind/src/UnwindRegistersSave.S stable/12/contrib/libunwind/src/assembly.h stable/12/contrib/llvm/lib/DebugInfo/DWARF/DWARFDebugFrame.cpp stable/12/contrib/llvm/lib/MC/ELFObjectWriter.cpp stable/12/contrib/llvm/lib/MC/MCWin64EH.cpp stable/12/contrib/llvm/lib/MC/WasmObjectWriter.cpp stable/12/contrib/llvm/lib/Object/COFFImportFile.cpp stable/12/contrib/llvm/lib/Target/AArch64/AArch64SchedExynosM4.td stable/12/contrib/llvm/lib/Target/AArch64/AArch64SchedPredExynos.td stable/12/contrib/llvm/lib/Target/AArch64/AArch64SchedPredicates.td stable/12/contrib/llvm/lib/Target/AMDGPU/SIFoldOperands.cpp stable/12/contrib/llvm/lib/Target/AMDGPU/VOP2Instructions.td stable/12/contrib/llvm/lib/Target/AVR/AVRISelLowering.cpp stable/12/contrib/llvm/lib/Target/AVR/AVRISelLowering.h stable/12/contrib/llvm/lib/Target/AVR/AVRSubtarget.cpp stable/12/contrib/llvm/lib/Target/AVR/AVRSubtarget.h stable/12/contrib/llvm/lib/Target/Mips/MCTargetDesc/MipsTargetStreamer.cpp stable/12/contrib/llvm/lib/Target/Mips/MicroMips32r6InstrInfo.td stable/12/contrib/llvm/lib/Target/Mips/MicroMipsInstrFPU.td stable/12/contrib/llvm/lib/Target/Mips/MipsAsmPrinter.cpp stable/12/contrib/llvm/lib/Target/Mips/MipsDSPInstrInfo.td stable/12/contrib/llvm/lib/Target/Mips/MipsDelaySlotFiller.cpp stable/12/contrib/llvm/lib/Target/Mips/MipsFastISel.cpp stable/12/contrib/llvm/lib/Target/Mips/MipsSEInstrInfo.cpp stable/12/contrib/llvm/lib/Target/PowerPC/Disassembler/PPCDisassembler.cpp stable/12/contrib/llvm/lib/Target/PowerPC/InstPrinter/PPCInstPrinter.cpp stable/12/contrib/llvm/lib/Target/PowerPC/MCTargetDesc/PPCMCTargetDesc.cpp stable/12/contrib/llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp stable/12/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td stable/12/contrib/llvm/lib/Target/PowerPC/PPCSubtarget.cpp stable/12/contrib/llvm/lib/Target/Sparc/SparcRegisterInfo.cpp stable/12/contrib/llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp stable/12/contrib/llvm/lib/Target/X86/X86FastISel.cpp stable/12/contrib/llvm/lib/Target/X86/X86TargetMachine.cpp stable/12/contrib/llvm/tools/clang/lib/AST/MicrosoftMangle.cpp stable/12/contrib/llvm/tools/clang/lib/Basic/Version.cpp stable/12/contrib/llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp stable/12/contrib/llvm/tools/clang/lib/CodeGen/CGStmtOpenMP.cpp stable/12/contrib/llvm/tools/clang/lib/Driver/ToolChains/Arch/PPC.cpp stable/12/contrib/llvm/tools/clang/lib/Driver/ToolChains/Clang.cpp stable/12/contrib/llvm/tools/clang/lib/Driver/ToolChains/Linux.cpp stable/12/contrib/llvm/tools/clang/lib/Sema/SemaOpenMP.cpp stable/12/contrib/llvm/tools/lld/COFF/Writer.cpp stable/12/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp stable/12/contrib/llvm/tools/lld/ELF/InputSection.cpp stable/12/contrib/llvm/tools/lld/ELF/SyntheticSections.cpp stable/12/contrib/llvm/tools/lld/ELF/Writer.cpp stable/12/contrib/llvm/tools/llvm-objdump/llvm-objdump.cpp stable/12/contrib/openmp/runtime/src/kmp_atomic.h stable/12/contrib/openmp/runtime/src/kmp_csupport.cpp stable/12/contrib/openmp/runtime/src/ompt-specific.cpp stable/12/etc/mtree/BSD.debug.dist stable/12/etc/mtree/BSD.usr.dist stable/12/lib/clang/freebsd_cc_version.h stable/12/lib/clang/headers/Makefile stable/12/lib/clang/include/clang/Basic/Version.inc stable/12/lib/clang/include/clang/Config/config.h stable/12/lib/clang/include/lld/Common/Version.inc stable/12/lib/clang/include/llvm/Config/config.h stable/12/lib/clang/include/llvm/Config/llvm-config.h stable/12/lib/clang/include/llvm/Support/VCSRevision.h stable/12/lib/clang/libllvm/Makefile stable/12/lib/libclang_rt/Makefile.inc stable/12/tools/build/mk/OptionalObsoleteFiles.inc stable/12/usr.bin/clang/Makefile A commit references this bug: Author: dim Date: Tue Jul 23 20:31:58 UTC 2019 New revision: 350259 URL: https://svnweb.freebsd.org/changeset/base/350259 Log: MFC r348504 (by kevans): llvm-symbolizer: Move out of CLANG_EXTRAS, into CLANG ASAN reports become a lot more useful with llvm-symbolizer in $PATH, and the build is not much more time-consuming. The added benefit is that the resulting reports will actually include symbol information; without, thread trace information includes a bunch of addresses that immediately resolve to an inline function in ^/contrib/compiler-rt/lib/sanitizer_common/sanitizer_common.h and take a little more effort to examine. Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D20484 MFC r348689 (by emaste): Use CLANG knob to remove llvm-symbolizer man page r348504 moved llvm-symbolizer from the CLANG_EXTRAS knob to CLANG, but the man page was still in the CLANG_EXTRAS section in OptionalObsoleteFiles.inc. Reported by: jhb MFC r349004: Upgrade our copies of clang, llvm, lld, lldb, compiler-rt, libc++, 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 r349351 (by jhibbits, partially): powerpc: Transition to Secure-PLT, like most other OSs (Toolchain part) Summary: Toolchain follow-up to r349350. LLVM patches will be submitted upstream for 9.0 as well. The bsd.cpu.mk change is required because GNU ld assumes BSS-PLT if it cannot determine for certain that it needs Secure-PLT, and some binaries do not compile in such a way to make it know to use Secure-PLT. Reviewed By: nwhitehorn, bdragon, pfg Differential Revision: https://reviews.freebsd.org/D20598 MFC r349793: Upgrade our copies of clang, llvm, lld, lldb, compiler-rt, libc++, 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 r350177: Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 8.0.1 final release r366581. The only functional change is a fix for a mismerge of upstream r360816, which properly restores the r2 register when unwinding on PowerPC64 (See https://reviews.freebsd.org/D20337). Relnotes: yes PR: 236062 Changes: _U stable/11/ stable/11/ObsoleteFiles.inc stable/11/UPDATING stable/11/contrib/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_netbsd.cc stable/11/contrib/libunwind/src/DwarfInstructions.hpp stable/11/contrib/libunwind/src/UnwindRegistersRestore.S stable/11/contrib/libunwind/src/UnwindRegistersSave.S stable/11/contrib/libunwind/src/assembly.h stable/11/contrib/llvm/lib/DebugInfo/DWARF/DWARFDebugFrame.cpp stable/11/contrib/llvm/lib/MC/ELFObjectWriter.cpp stable/11/contrib/llvm/lib/MC/MCWin64EH.cpp stable/11/contrib/llvm/lib/MC/WasmObjectWriter.cpp stable/11/contrib/llvm/lib/Object/COFFImportFile.cpp stable/11/contrib/llvm/lib/Target/AArch64/AArch64SchedExynosM4.td stable/11/contrib/llvm/lib/Target/AArch64/AArch64SchedPredExynos.td stable/11/contrib/llvm/lib/Target/AArch64/AArch64SchedPredicates.td stable/11/contrib/llvm/lib/Target/AMDGPU/SIFoldOperands.cpp stable/11/contrib/llvm/lib/Target/AMDGPU/VOP2Instructions.td stable/11/contrib/llvm/lib/Target/AVR/AVRISelLowering.cpp stable/11/contrib/llvm/lib/Target/AVR/AVRISelLowering.h stable/11/contrib/llvm/lib/Target/AVR/AVRSubtarget.cpp stable/11/contrib/llvm/lib/Target/AVR/AVRSubtarget.h stable/11/contrib/llvm/lib/Target/Mips/MCTargetDesc/MipsTargetStreamer.cpp stable/11/contrib/llvm/lib/Target/Mips/MicroMips32r6InstrInfo.td stable/11/contrib/llvm/lib/Target/Mips/MicroMipsInstrFPU.td stable/11/contrib/llvm/lib/Target/Mips/MipsAsmPrinter.cpp stable/11/contrib/llvm/lib/Target/Mips/MipsDSPInstrInfo.td stable/11/contrib/llvm/lib/Target/Mips/MipsDelaySlotFiller.cpp stable/11/contrib/llvm/lib/Target/Mips/MipsFastISel.cpp stable/11/contrib/llvm/lib/Target/Mips/MipsSEInstrInfo.cpp stable/11/contrib/llvm/lib/Target/PowerPC/Disassembler/PPCDisassembler.cpp stable/11/contrib/llvm/lib/Target/PowerPC/InstPrinter/PPCInstPrinter.cpp stable/11/contrib/llvm/lib/Target/PowerPC/MCTargetDesc/PPCMCTargetDesc.cpp stable/11/contrib/llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp stable/11/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td stable/11/contrib/llvm/lib/Target/PowerPC/PPCSubtarget.cpp stable/11/contrib/llvm/lib/Target/Sparc/SparcRegisterInfo.cpp stable/11/contrib/llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp stable/11/contrib/llvm/lib/Target/X86/X86FastISel.cpp stable/11/contrib/llvm/lib/Target/X86/X86TargetMachine.cpp stable/11/contrib/llvm/tools/clang/lib/AST/MicrosoftMangle.cpp stable/11/contrib/llvm/tools/clang/lib/Basic/Version.cpp stable/11/contrib/llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp stable/11/contrib/llvm/tools/clang/lib/CodeGen/CGStmtOpenMP.cpp stable/11/contrib/llvm/tools/clang/lib/Driver/ToolChains/Arch/PPC.cpp stable/11/contrib/llvm/tools/clang/lib/Driver/ToolChains/Clang.cpp stable/11/contrib/llvm/tools/clang/lib/Driver/ToolChains/Linux.cpp stable/11/contrib/llvm/tools/clang/lib/Sema/SemaOpenMP.cpp stable/11/contrib/llvm/tools/lld/COFF/Writer.cpp stable/11/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp stable/11/contrib/llvm/tools/lld/ELF/InputSection.cpp stable/11/contrib/llvm/tools/lld/ELF/SyntheticSections.cpp stable/11/contrib/llvm/tools/lld/ELF/Writer.cpp stable/11/contrib/llvm/tools/llvm-objdump/llvm-objdump.cpp stable/11/contrib/openmp/runtime/src/kmp_atomic.h stable/11/contrib/openmp/runtime/src/kmp_csupport.cpp stable/11/contrib/openmp/runtime/src/ompt-specific.cpp stable/11/etc/mtree/BSD.debug.dist stable/11/etc/mtree/BSD.usr.dist stable/11/lib/clang/freebsd_cc_version.h stable/11/lib/clang/headers/Makefile stable/11/lib/clang/include/clang/Basic/Version.inc stable/11/lib/clang/include/clang/Config/config.h stable/11/lib/clang/include/lld/Common/Version.inc stable/11/lib/clang/include/llvm/Config/config.h stable/11/lib/clang/include/llvm/Config/llvm-config.h stable/11/lib/clang/include/llvm/Support/VCSRevision.h stable/11/lib/clang/libllvm/Makefile stable/11/lib/libclang_rt/Makefile.inc stable/11/tools/build/mk/OptionalObsoleteFiles.inc stable/11/usr.bin/clang/Makefile |