Bug 236062 - [exp-run] Against projects/clang800-import branch
Summary: [exp-run] Against projects/clang800-import branch
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Ports Framework (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Port Management Team
URL:
Keywords:
: 222858 (view as bug list)
Depends on: 236141 236213 236566 236567 236061 236192 236193 236194 236205 236206 236207 236209 236210 236211 236212 236214 236215 236216 236217 236313 236326 236568 236581 236582 237975 238082
Blocks: 236907
  Show dependency treegraph
 
Reported: 2019-02-26 18:56 UTC by Dimitry Andric
Modified: 2019-07-23 20:32 UTC (History)
7 users (show)

See Also:
antoine: exp-run?


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dimitry Andric freebsd_committer 2019-02-26 18:56:16 UTC
I am importing llvm, clang, compiler-rt, libc++, ldd and lldb 8.0.0 into the projects/clang800-import branch.

As of 2019-02-25, this branch contains the equivalent of upstream's 8.0.0 rc2, and it has been synchronized with head r344548.

Please perform an exp-run against this branch.

[for convenience, bug 230355 was the previous clang 7.0.0 exp-run]
Comment 1 Dimitry Andric freebsd_committer 2019-02-26 18:57:55 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.
Comment 2 Antoine Brodin freebsd_committer 2019-03-02 20:27:37 UTC
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
Comment 3 Jan Beich freebsd_committer 2019-03-04 17:15:13 UTC
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.
Comment 4 Dimitry Andric freebsd_committer 2019-03-04 18:11:58 UTC
(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.
Comment 5 Ed Maste freebsd_committer 2019-03-04 18:31:22 UTC
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?
Comment 6 Jan Beich freebsd_committer 2019-03-04 20:32:09 UTC
(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.
Comment 7 Ed Maste freebsd_committer 2019-03-04 20:52:14 UTC
(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.
Comment 8 Antoine Brodin freebsd_committer 2019-03-04 20:57:28 UTC
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
Comment 9 Jan Beich freebsd_committer 2019-03-04 21:08:04 UTC
(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
Comment 10 Antoine Brodin freebsd_committer 2019-03-05 14:27:53 UTC
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)
Comment 11 commit-hook freebsd_committer 2019-03-09 00:28:43 UTC
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
Comment 12 commit-hook freebsd_committer 2019-03-11 18:46:22 UTC
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
Comment 13 commit-hook freebsd_committer 2019-03-11 18:56:33 UTC
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
Comment 14 commit-hook freebsd_committer 2019-03-12 18:20:09 UTC
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
Comment 15 commit-hook freebsd_committer 2019-03-14 19:53:13 UTC
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
Comment 16 commit-hook freebsd_committer 2019-03-16 13:41:20 UTC
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/
Comment 17 commit-hook freebsd_committer 2019-03-16 13:42:24 UTC
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/
Comment 18 commit-hook freebsd_committer 2019-03-16 13:43:27 UTC
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
Comment 19 commit-hook freebsd_committer 2019-03-16 13:45:32 UTC
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
Comment 20 commit-hook freebsd_committer 2019-03-16 15:02:34 UTC
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
Comment 21 commit-hook freebsd_committer 2019-03-16 15:46:15 UTC
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
Comment 22 commit-hook freebsd_committer 2019-03-16 17:56:08 UTC
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
Comment 23 commit-hook freebsd_committer 2019-03-17 11:28:05 UTC
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
Comment 24 commit-hook freebsd_committer 2019-03-18 19:11:44 UTC
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
Comment 25 commit-hook freebsd_committer 2019-03-18 19:56:27 UTC
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
Comment 26 commit-hook freebsd_committer 2019-03-18 21:04:36 UTC
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
Comment 27 commit-hook freebsd_committer 2019-03-19 06:59:07 UTC
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
Comment 28 commit-hook freebsd_committer 2019-03-20 19:19:12 UTC
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
Comment 29 commit-hook freebsd_committer 2019-03-20 20:57:38 UTC
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
Comment 31 Dimitry Andric freebsd_committer 2019-03-21 21:03:08 UTC
(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? :)
Comment 32 commit-hook freebsd_committer 2019-03-23 14:10:51 UTC
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
Comment 33 commit-hook freebsd_committer 2019-04-17 20:08:57 UTC
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
Comment 34 commit-hook freebsd_committer 2019-04-17 20:09:01 UTC
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
Comment 35 commit-hook freebsd_committer 2019-04-17 20:09:08 UTC
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
Comment 36 commit-hook freebsd_committer 2019-04-17 20:09:10 UTC
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
Comment 37 commit-hook freebsd_committer 2019-04-17 20:09:13 UTC
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
Comment 38 commit-hook freebsd_committer 2019-04-17 20:09:20 UTC
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
Comment 39 commit-hook freebsd_committer 2019-04-17 20:17:29 UTC
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
Comment 40 commit-hook freebsd_committer 2019-04-17 20:17:32 UTC
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
Comment 41 commit-hook freebsd_committer 2019-04-17 20:17:34 UTC
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
Comment 42 commit-hook freebsd_committer 2019-04-17 20:17:39 UTC
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
Comment 43 commit-hook freebsd_committer 2019-04-17 20:17:42 UTC
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
Comment 44 commit-hook freebsd_committer 2019-04-17 20:17:48 UTC
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
Comment 45 Jan Beich freebsd_committer 2019-04-22 18:34:20 UTC
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
Comment 46 Jan Beich freebsd_committer 2019-04-22 18:38:41 UTC
Nevermind comment 45. I didn't notice base r344213.
Comment 47 Jan Beich freebsd_committer 2019-05-19 03:32:20 UTC
*** Bug 222858 has been marked as a duplicate of this bug. ***
Comment 48 commit-hook freebsd_committer 2019-07-20 15:27:06 UTC
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
Comment 49 commit-hook freebsd_committer 2019-07-23 18:41:19 UTC
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
Comment 50 commit-hook freebsd_committer 2019-07-23 20:32:35 UTC
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