|
Revision tags: release/12.2.0, release/11.4.0, release/12.1.0, release/11.3.0 |
|
| #
f5e04876 |
| 23-May-2019 |
Enji Cooper <[email protected]> |
MFC r345203,r345205,r345353,r345645,r345708,r345709,r345735,r345770,r346081,r346270,r346574,r346576:
r345203:
Initial googlemock/googletest integration into the build/FreeBSD test suite
This initi
MFC r345203,r345205,r345353,r345645,r345708,r345709,r345735,r345770,r346081,r346270,r346574,r346576:
r345203:
Initial googlemock/googletest integration into the build/FreeBSD test suite
This initial integration takes googlemock/googletest release 1.8.1, integrates the library, tests, and sample unit tests into the build.
googlemock/googletest's inclusion is optionally available via `MK_GOOGLETEST`. `MK_GOOGLETEST` is dependent on `MK_TESTS` and is enabled by default when built with a C++11 capable toolchain.
Google tests can be specified via the `GTESTS` variable, which, in comparison with the other test drivers, is more simplified/streamlined, as Googletest only supports C++ tests; not raw C or shell tests (C tests can be written in C++ using the standard embedding methods).
No dependent libraries are assumed for the tests. One must specify `gmock`, `gmock_main`, `gtest`, or `gtest_main`, via `LIBADD` for the program.
More information about googlemock and googletest can be found on the Googletest [project page](https://github.com/google/googletest), and the [GoogleMock](https://github.com/google/googletest/blob/v1.8.x/googlemock/docs/Documentation.md) and [GoogleTest](https://github.com/google/googletest/tree/v1.8.x/googletest/docs) docs.
These tests are originally integrated into the build as plain driver tests, but will be natively integrated into Kyua in a later version.
Known issues/Errata: * [WhenDynamicCastToTest.AmbiguousCast fails on FreeBSD](https://github.com/google/googletest/issues/2172)
r345205:
Integrate cddl/usr.sbin/zfds/tests into the FreeBSD test suite
This change integrates the unit tests for zfsd into the test suite using the integration method described in r345203.
This change removes the `LOCALBASE` includes added for the port version of googlemock/googletest, as well as unnecessary `LIBADD`/`DPADD` and `CXXFLAGS` defines, which are included in the `GTEST_CXXFLAGS` variable, as part of r345203.
r345353 (by asomers):
googletest: backport GTEST_SKIP to googletest 1.8.1
This commit backports revisions 00938b2b228f3b70d3d9e51f29a1505bdad43f1e and 59f90a338bce2376b540ee239cf4e269bf6d68ad from googletest's master branch to our included version of googletest, which is based on 1.8.1. It adds the GTEST_SKIP feature, which is very useful for a project like FreeBSD where some tests depend on particular system configurations.
Obtained from: github.com/google/googletest
r345645:
Spam CXXFLAGS with `-I${DESTDIR}/usr/include/private`, instead of GTEST_CXXFLAGS
This makes it easier for googletest users to leverage googletest, instead of forcing them to plug GTEST_CXXFLAGS into CXXFLAGS manually (resulting in unnecessary duplication).
I will be following this up with a more proper fix in src.libnames.mk, as src.libnames.mk should be automatically adding this directory to CFLAGS/CXXFLAGS when private libraries are referenced. Not doing so can result in mismatches between base-provided private library's and ports-provided library's headers.
While here, tweak the comment to clarify what the intent is behind spamming CXXFLAGS.
r345708:
Standardize `-std=c++* as `CXXSTD`
CXXSTD was added as the C++ analogue to CSTD.
CXXSTD defaults to `-std=c++11` with supporting compilers; `-std=gnu++98`, otherwise for older versions of g++.
This change standardizes the CXXSTD variable, originally added to googletest.test.inc.mk as part of r345203.
As part of this effort, convert all `CXXFLAGS+= -std=*` calls to use `CXXSTD`.
Notes:
This value is not sanity checked in bsd.sys.mk, however, given the two most used C++ compilers on FreeBSD (clang++ and g++) support both modes, it is likely to work with both toolchains. This method will be refined in the future to support more variants of C++, as not all versions of clang++ and g++ (for instance) support C++14, C++17, etc.
Any manual appending of `-std=*` to `CXXFLAGS` should be replaced with CXXSTD. Example:
Before this commit: ``` CXXFLAGS+= -std=c++14 ```
After this commit: ``` CXXSTD= c++14 ```
Relnotes: yes Tested with: make tinderbox
r345709:
Allow users to override CSTD/CXXSTD on a per-prog basis
The current logic for CSTD/CXXSTD requires homogenity as far as the supported C/C++ standards, which is a sensible default. However, when dealing with differing versions of C++, some code may compile with C++11, but not C++17 (for instance). So in order to avoid having people convert over their code to the new standard, give the users the ability to specify the standard on a per-program basis.
This will allow a user to override the supporting standard for a set of programs, mixing C++11 with C++14 (for instance).
Apprved by: emaste (mentor)
r345735:
Allow programs to set `NO_SHARED` on a per-PROG basis
This is particularly useful when installing programs for tests that need to be linked statically, e.g., mini-me from capsicum-test, which is linked statically to avoid the dynamic library lookup in the upstream project.
r345770:
Import proof-of-concept for handling `GTEST_SKIP()` in `Environment::SetUp`
Per the upstream pull-request [1]:
``` gtest prior to this change would completely ignore `GTEST_SKIP()` if called in `Environment::SetUp()`, instead of bailing out early, unlike `Test::SetUp()`, which would cause the tests themselves to be skipped. The only way (prior to this change) to skip the tests would be to trigger a fatal error via `GTEST_FAIL()`.
Desirable behavior, in this case, when dealing with `Environment::SetUp()` is to check for prerequisites on a system (example, kernel supports a particular featureset, e.g., capsicum), and skip the tests. The alternatives prior to this change would be undesirable:
- Failing sends the wrong message to the test user, as the result of the tests is indeterminate, not failed. - Having to add per-test class abstractions that override `SetUp()` to test for the capsicum feature set, then skip all of the tests in their respective SetUp fixtures, would be a lot of human and computational work; checking for the feature would need to be done for all of the tests, instead of once for all of the tests.
For those reasons, making `Environment::SetUp()` handle `GTEST_SKIP()`, by not executing the testcases, is the most desirable solution.
In order to properly diagnose what happened when running the tests if they are skipped, print out the diagnostics in an ad hoc manner.
Update the documentation to note this change and integrate a new test, gtest_skip_in_environment_setup_test, into the test suite.
This change addresses #2189.
Signed-off-by: Enji Cooper <[email protected]> ```
The goal with my merging in this change is to avoid requiring extensive refactoring/retesting of test suites when ensuring prerequisites are met, e.g., checking for a CAPABILITIES-enabled kernel before running capsicum-test (see D19758 for more details).
The proof-of-concept is being imported before accepted by the upstream project due to the fact that the upstream project is undergoing a potential development freeze and the maintainers aren't responding to my PR.
1. https://github.com/google/googletest/pull/2203
r346081 (by trasz):
Make zfsd(8) build obey CFLAGS.
Obtained from: CheriBSD
r346270 (by trasz):
Drop -g from CFLAGS for zfsd(8). No idea why it was ever there.
r346574:
Rework CXXSTD setting via r345708
This change allows the user to once again override the C++ standard, restoring high-level pre-r345708 behavior.
This also unbreaks building lib/ofed/libibnetdisc/Makefile with a non-C++11 capable compiler, e.g., g++ 4.2.1, as the library supported being built with older C++ standards.
r346576:
Fix up CXXSTD support originally added in r345708
r345708 worked for the base system, but unfortunately, caused a lot of disruption for third-party packages that relied on C++, since bsd.sys.mk is used by applications outside the base system. The defaults picked didn't match the compiler's defaults and broke some builds that didn't specify a standard, as well as some that overrode the value by setting `-std=gnu++14` (for example) manually.
This change takes a more relaxed approach to appending `-std=${CXXSTD}` to CXXFLAGS, by only doing so when the value is specified, as opposed to overriding the standard set by an end-user. This avoids the need for having to bake NOP default into bsd.sys.mk for supported compiler-toolchain versions.
In order to make this change possible, add CXXSTD to Makefile snippets which relied on the default value (c++11) added in r345708.
show more ...
|
| #
df407fbc |
| 23-May-2019 |
Enji Cooper <[email protected]> |
Revert r348136
I accidentally committed some unrelated local changes to `.../tests/sys/opencrypto` along with this MFC set.
|
| #
e787ffab |
| 23-May-2019 |
Enji Cooper <[email protected]> |
MFC r345203,r345205,r345353,r345645,r345708,r345709,r345735,r345770,r346574,r346576:
r345203:
Initial googlemock/googletest integration into the build/FreeBSD test suite
This initial integration t
MFC r345203,r345205,r345353,r345645,r345708,r345709,r345735,r345770,r346574,r346576:
r345203:
Initial googlemock/googletest integration into the build/FreeBSD test suite
This initial integration takes googlemock/googletest release 1.8.1, integrates the library, tests, and sample unit tests into the build.
googlemock/googletest's inclusion is optionally available via `MK_GOOGLETEST`. `MK_GOOGLETEST` is dependent on `MK_TESTS` and is enabled by default when built with a C++11 capable toolchain.
Google tests can be specified via the `GTESTS` variable, which, in comparison with the other test drivers, is more simplified/streamlined, as Googletest only supports C++ tests; not raw C or shell tests (C tests can be written in C++ using the standard embedding methods).
No dependent libraries are assumed for the tests. One must specify `gmock`, `gmock_main`, `gtest`, or `gtest_main`, via `LIBADD` for the program.
More information about googlemock and googletest can be found on the Googletest [project page](https://github.com/google/googletest), and the [GoogleMock](https://github.com/google/googletest/blob/v1.8.x/googlemock/docs/Documentation.md) and [GoogleTest](https://github.com/google/googletest/tree/v1.8.x/googletest/docs) docs.
These tests are originally integrated into the build as plain driver tests, but will be natively integrated into Kyua in a later version.
Known issues/Errata: * [WhenDynamicCastToTest.AmbiguousCast fails on FreeBSD](https://github.com/google/googletest/issues/2172)
r345205:
Integrate cddl/usr.sbin/zfds/tests into the FreeBSD test suite
This change integrates the unit tests for zfsd into the test suite using the integration method described in r345203.
This change removes the `LOCALBASE` includes added for the port version of googlemock/googletest, as well as unnecessary `LIBADD`/`DPADD` and `CXXFLAGS` defines, which are included in the `GTEST_CXXFLAGS` variable, as part of r345203.
r345353 (by asomers):
googletest: backport GTEST_SKIP to googletest 1.8.1
This commit backports revisions 00938b2b228f3b70d3d9e51f29a1505bdad43f1e and 59f90a338bce2376b540ee239cf4e269bf6d68ad from googletest's master branch to our included version of googletest, which is based on 1.8.1. It adds the GTEST_SKIP feature, which is very useful for a project like FreeBSD where some tests depend on particular system configurations.
Obtained from: github.com/google/googletest
r345645:
Spam CXXFLAGS with `-I${DESTDIR}/usr/include/private`, instead of GTEST_CXXFLAGS
This makes it easier for googletest users to leverage googletest, instead of forcing them to plug GTEST_CXXFLAGS into CXXFLAGS manually (resulting in unnecessary duplication).
I will be following this up with a more proper fix in src.libnames.mk, as src.libnames.mk should be automatically adding this directory to CFLAGS/CXXFLAGS when private libraries are referenced. Not doing so can result in mismatches between base-provided private library's and ports-provided library's headers.
While here, tweak the comment to clarify what the intent is behind spamming CXXFLAGS.
r345708:
Standardize `-std=c++* as `CXXSTD`
CXXSTD was added as the C++ analogue to CSTD.
CXXSTD defaults to `-std=c++11` with supporting compilers; `-std=gnu++98`, otherwise for older versions of g++.
This change standardizes the CXXSTD variable, originally added to googletest.test.inc.mk as part of r345203.
As part of this effort, convert all `CXXFLAGS+= -std=*` calls to use `CXXSTD`.
Notes:
This value is not sanity checked in bsd.sys.mk, however, given the two most used C++ compilers on FreeBSD (clang++ and g++) support both modes, it is likely to work with both toolchains. This method will be refined in the future to support more variants of C++, as not all versions of clang++ and g++ (for instance) support C++14, C++17, etc.
Any manual appending of `-std=*` to `CXXFLAGS` should be replaced with CXXSTD. Example:
Before this commit: ``` CXXFLAGS+= -std=c++14 ```
After this commit: ``` CXXSTD= c++14 ```
Relnotes: yes Tested with: make tinderbox
r345709:
Allow users to override CSTD/CXXSTD on a per-prog basis
The current logic for CSTD/CXXSTD requires homogenity as far as the supported C/C++ standards, which is a sensible default. However, when dealing with differing versions of C++, some code may compile with C++11, but not C++17 (for instance). So in order to avoid having people convert over their code to the new standard, give the users the ability to specify the standard on a per-program basis.
This will allow a user to override the supporting standard for a set of programs, mixing C++11 with C++14 (for instance).
Approved by: emaste (mentor)
r345735:
Allow programs to set `NO_SHARED` on a per-PROG basis
This is particularly useful when installing programs for tests that need to be linked statically, e.g., mini-me from capsicum-test, which is linked statically to avoid the dynamic library lookup in the upstream project.
r345770:
Import proof-of-concept for handling `GTEST_SKIP()` in `Environment::SetUp`
Per the upstream pull-request [1]:
``` gtest prior to this change would completely ignore `GTEST_SKIP()` if called in `Environment::SetUp()`, instead of bailing out early, unlike `Test::SetUp()`, which would cause the tests themselves to be skipped. The only way (prior to this change) to skip the tests would be to trigger a fatal error via `GTEST_FAIL()`.
Desirable behavior, in this case, when dealing with `Environment::SetUp()` is to check for prerequisites on a system (example, kernel supports a particular featureset, e.g., capsicum), and skip the tests. The alternatives prior to this change would be undesirable:
- Failing sends the wrong message to the test user, as the result of the tests is indeterminate, not failed. - Having to add per-test class abstractions that override `SetUp()` to test for the capsicum feature set, then skip all of the tests in their respective SetUp fixtures, would be a lot of human and computational work; checking for the feature would need to be done for all of the tests, instead of once for all of the tests.
For those reasons, making `Environment::SetUp()` handle `GTEST_SKIP()`, by not executing the testcases, is the most desirable solution.
In order to properly diagnose what happened when running the tests if they are skipped, print out the diagnostics in an ad hoc manner.
Update the documentation to note this change and integrate a new test, gtest_skip_in_environment_setup_test, into the test suite.
This change addresses #2189.
Signed-off-by: Enji Cooper <[email protected]> ```
The goal with my merging in this change is to avoid requiring extensive refactoring/retesting of test suites when ensuring prerequisites are met, e.g., checking for a CAPABILITIES-enabled kernel before running capsicum-test (see D19758 for more details).
The proof-of-concept is being imported before accepted by the upstream project due to the fact that the upstream project is undergoing a potential development freeze and the maintainers aren't responding to my PR.
1. https://github.com/google/googletest/pull/2203
r346574:
Rework CXXSTD setting via r345708
This change allows the user to once again override the C++ standard, restoring high-level pre-r345708 behavior.
This also unbreaks building lib/ofed/libibnetdisc/Makefile with a non-C++11 capable compiler, e.g., g++ 4.2.1, as the library supported being built with older C++ standards.
r346576:
Fix up CXXSTD support originally added in r345708
r345708 worked for the base system, but unfortunately, caused a lot of disruption for third-party packages that relied on C++, since bsd.sys.mk is used by applications outside the base system. The defaults picked didn't match the compiler's defaults and broke some builds that didn't specify a standard, as well as some that overrode the value by setting `-std=gnu++14` (for example) manually.
This change takes a more relaxed approach to appending `-std=${CXXSTD}` to CXXFLAGS, by only doing so when the value is specified, as opposed to overriding the standard set by an end-user. This avoids the need for having to bake NOP default into bsd.sys.mk for supported compiler-toolchain versions.
In order to make this change possible, add CXXSTD to Makefile snippets which relied on the default value (c++11) added in r345708.
show more ...
|
| #
b5893f02 |
| 12-Apr-2019 |
Dimitry Andric <[email protected]> |
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 8.0.0 final release r356365.
MFC r340287 (by emaste):
Consolidate gcov entries in OptionalObsoleteFiles
Sponsored by: The Fr
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 8.0.0 final release r356365.
MFC r340287 (by emaste):
Consolidate gcov entries in OptionalObsoleteFiles
Sponsored by: The FreeBSD Foundation
MFC r340289 (by emaste):
llvm-cov: also install as gcov (if GNU gcov is disabled)
llvm-cov provides a gcov-compatible interface when invoked as gcov.
Reviewed by: dim, markj Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D17923
MFC r340296 (by emaste):
Move llvm-profdata build into MK_LLVM_COV block
llvm-profdata is used with llvm-cov for code coverage (although llvm-cov can also operate independently in a gcov-compatible mode). Although llvm-profdata can be used independently of llvm-cov it makes sense to group these under one option.
Also handle these in OptionalObsoleteFiles.inc while here.
Sponsored by: The FreeBSD Foundation
MFC r340300 (by emaste):
libllvm: Move SampleProfWriter to SRCS_MIN
It is required by llvm-profdata, now built by default under the LLVM_COV knob. The additional complexity that would come from avoiding building it if CLANG_EXTRAS and LLVM_COV are both disabled is not worth the small savings in build time.
Sponsored by: The FreeBSD Foundation
MFC r340972 (by emaste):
llvm-objdump: initial man page
Based on llvm-objdump's online documentation and usage information. This serves as a starting point; additional detail and cleanup still required.
Also being submitted upstream in LLVM review D54864. I expect to use this bespoke copy while we have LLVM 6.0 or 7.0 in FreeBSD; when we update to LLVM 8.0 it should be upstream and we will switch to it.
PR: 233437 Reviewed by: bcr (man formatting) Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D18309
MFC r340973 (by emaste):
llvm-objdump.1: remove invalid options
Some options appear in llvm-objdump's usage information as a side effect of its option parsing implementation and are not actually llvm-objdump options. Reported in LLVM review https://reviews.llvm.org/D54864.
Reported by: Fangrui Song Sponsored by: The FreeBSD Foundation
MFC r340975 (by emaste):
llvm-objdump.1: fix igor / mandoc -Tlint warnings
Accidentally omitted from r340972.
MFC r341055 (by emaste):
llvm-objdump.1: remove more unintentional options
Some options come from static constructors in LLVM libraries and are automatically added to llvm's usage output. They're not really supposed to be llvm-objdump options.
Reported by: Fangrui Song in LLVM review D54864 Sponsored by: The FreeBSD Foundation
MFC r344779:
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_80 branch r355313 (effectively, 8.0.0 rc3). The release will follow very soon, but no more functional changes are expected.
Release notes for llvm, clang and lld 8.0.0 will soon be available here: <https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/clang/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/lld/docs/ReleaseNotes.html>
PR: 236062 Relnotes: yes
MFC r344798 (by emaste):
libllvm: promote WithColor and xxhash to SRCS_MIN
The armv6 build failed in CI due to missing symbols (from these two source files) in the bootstrap Clang.
This affected only armv6 because other Clang-using archs are using LLD as the bootstrap linker, and thus include SRCS_MIW via LLD_BOOTSTRAP.
Reported by: CI, via lwhsu Sponsored by: The FreeBSD Foundation
MFC r344825:
Add a few missed files to the MK_LLVM_TARGET_BPF=yes case, otherwise clang and various other executables will fail to link with undefined symbols.
Reported by: O. Hartmann <[email protected]>
MFC r344852:
Put in a temporary workaround for what is likely a gcc 6 bug (it does not occur with gcc 7 or later). This should prevent the following error from breaking the head-amd64-gcc CI builds:
In file included from /workspace/src/contrib/llvm/tools/lldb/source/API/SBMemoryRegionInfo.cpp:14:0: /workspace/src/contrib/llvm/tools/lldb/include/lldb/Target/MemoryRegionInfo.h:128:54: error: 'template<class _InputIterator> lldb_private::MemoryRegionInfos::MemoryRegionInfos(_InputIterator, _InputIterator, const allocator_type&)' inherited from 'std::__1::vector<lldb_private::MemoryRegionInfo>' using std::vector<lldb_private::MemoryRegionInfo>::vector; ^~~~~~ /workspace/src/contrib/llvm/tools/lldb/include/lldb/Target/MemoryRegionInfo.h:128:54: error: conflicts with version inherited from 'std::__1::vector<lldb_private::MemoryRegionInfo>'
Reported by: CI
MFC r344896:
Pull in r354937 from upstream clang trunk (by Jörg Sonnenberger):
Fix inline assembler constraint validation
The current constraint logic is both too lax and too strict. It fails for input outside the [INT_MIN..INT_MAX] range, but it also implicitly accepts 0 as value when it should not. Adjust logic to handle both correctly.
Differential Revision: https://reviews.llvm.org/D58649
Pull in r355491 from upstream clang trunk (by Hans Wennborg):
Inline asm constraints: allow ICE-like pointers for the "n" constraint (PR40890)
Apparently GCC allows this, and there's code relying on it (see bug).
The idea is to allow expression that would have been allowed if they were cast to int. So I based the code on how such a cast would be done (the CK_PointerToIntegral case in IntExprEvaluator::VisitCastExpr()).
Differential Revision: https://reviews.llvm.org/D58821
These should fix assertions and errors when using the inline assembly "n" constraint in certain ways.
In case of devel/valgrind, a pointer was used as the input for the constraint, which lead to "Assertion failed: (isInt() && "Invalid accessor"), function getInt".
In case of math/secp256k1, a very large integer value was used as input for the constraint, which lead to "error: value '4624529908474429119' out of range for constraint 'n'".
PR: 236216, 236194
MFC r344951:
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 r345018:
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 r345019:
Merge LLVM libunwind release_80 branch r355677 (effectively, 8.0.0 rc4).
PR: 236062
MFC r345021:
Pull in r355854 from upstream llvm trunk (by Jonas Paulsson):
[RegAlloc] Avoid compile time regression with multiple copy hints.
As a fix for https://bugs.llvm.org/show_bug.cgi?id=40986 ("excessive compile time building opencollada"), this patch makes sure that no phys reg is hinted more than once from getRegAllocationHints().
This handles the case were many virtual registers are assigned to the same physreg. The previous compile time fix (r343686) in weightCalcHelper() only made sure that physical/virtual registers are passed no more than once to addRegAllocationHint().
Review: Dimitry Andric, Quentin Colombet https://reviews.llvm.org/D59201
This should fix a hang when compiling certain generated .cpp files in the graphics/opencollada port.
PR: 236313
MFC r345068 (by jhb):
Move libunwind out of contrib/llvm/projects.
Move LLVM's libunwind to its own contrib/ directory similar to other runtime libraries like libc++ and libcxxrt.
Reviewed by: dim, emaste Differential Revision: https://reviews.freebsd.org/D19534
MFC r345073:
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 r345152:
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 r345231:
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 r345232:
Bootstrap svn:mergeinfo on contrib/openmp.
PR: 236062
MFC r345233:
Merge openmp release_80 branch r356034 (effectively, 8.0.0 rc5).
PR: 236062
MFC r345234:
Add openmp __kmp_gettid() wrapper, using pthread_getthreadid_np(3). This has also been submitted upstream.
PR: 236062
MFC r345283:
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 r345345:
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 r345349:
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 r345449:
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
show more ...
|
| #
ae8c08e7 |
| 12-Apr-2019 |
Simon J. Gerraty <[email protected]> |
Add support for loader veriexec
Also sbin/veriexec for mac_veriexec
MFC r343281,344564-344568,344780,344784,345289,346070
|
| #
4ba319b5 |
| 16-Feb-2019 |
Dimitry Andric <[email protected]> |
Merge clang 7.0.1 and several follow-up changes
MFC r341825:
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_70 branch r348686 (effectively, 7.0.1 rc3).
Merge clang 7.0.1 and several follow-up changes
MFC r341825:
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_70 branch r348686 (effectively, 7.0.1 rc3). The release will follow very soon, but no more functional changes are expected.
Release notes for llvm, clang and lld 7.0.0 are available here: <http://releases.llvm.org/7.0.0/docs/ReleaseNotes.html> <http://releases.llvm.org/7.0.0/tools/clang/docs/ReleaseNotes.html> <http://releases.llvm.org/7.0.0/tools/lld/docs/ReleaseNotes.html>
PR: 230240, 230355 Relnotes: yes
MFC r342123:
Update clang, llvm, lld, lldb, compiler-rt and libc++ version number to 7.0.1 release r349250. There were no functional changes since the 7.0.1 rc3 import.
PR: 230240, 230355 Relnotes: yes
r343429 | emaste | 2019-01-25 15:46:13 +0100 (Fri, 25 Jan 2019) | 16 lines
clang: default to DWARF 4 as of FreeBSD 13
FreeBSD previously defaulted to DWARF 2 because several tools (gdb, ctfconvert, etc.) did not support later versions. These have either been fixed or are deprecated.
Note that gdb 6 still exists but has been moved out of $PATH into /usr/libexec and is intended only for use by crashinfo(8). The kernel build sets the DWARF version explicitly via -gdwarf2, so this should have no effect there.
PR: 234887 [exp-run] Reviewed by: markj Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D17930
MFC r343916:
Pull in r352607 from upstream llvm trunk (by Craig Topper):
[X86] Add FPSW as a Def on some FP instructions that were missing it.
Pull in r353141 from upstream llvm trunk (by Craig Topper):
[X86] Connect the default fpsr and dirflag clobbers in inline assembly to the registers we have defined for them.
Summary: We don't currently map these constraints to physical register numbers so they don't make it to the MachineIR representation of inline assembly.
This could have problems for proper dependency tracking in the machine schedulers though I don't have a test case that shows that.
Reviewers: rnk
Reviewed By: rnk
Subscribers: eraman, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57641
Pull in r353489 from upstream llvm trunk (by Craig Topper):
[X86] Add FPCW as a register and start using it as an implicit use on floating point instructions.
Summary: FPCW contains the rounding mode control which we manipulate to implement fp to integer conversion by changing the roudning mode, storing the value to the stack, and then changing the rounding mode back. Because we didn't model FPCW and its dependency chain, other instructions could be scheduled into the middle of the sequence.
This patch introduces the register and adds it as an implciit def of FLDCW and implicit use of the FP binary arithmetic instructions and store instructions. There are more instructions that need to be updated, but this is a good start. I believe this fixes at least the reduced test case from PR40529.
Reviewers: RKSimon, spatel, rnk, efriedma, andrew.w.kaylor
Subscribers: dim, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57735
These should fix a problem in clang 7.0 where it would sometimes emit long double floating point instructions in a slightly wrong order, leading to failures in our libm tests. In particular, the cbrt_test test case 'cbrtl_powl' and the trig_test test case 'reduction'.
Also bump __FreeBSD_cc_version, to be able to detect this in our test suite.
Reported by: lwhsu PR: 234040 Upstream PR: https://bugs.llvm.org/show_bug.cgi?id=40206
MFC r344056:
Pull in r339734 from upstream llvm trunk (by Eli Friedman):
[ARM] Make PerformSHLSimplify add nodes to the DAG worklist correctly.
Intentionally excluding nodes from the DAGCombine worklist is likely to lead to weird optimizations and infinite loops, so it's generally a bad idea.
To avoid the infinite loops, fix DAGCombine to use the isDesirableToCommuteWithShift target hook before performing the transforms in question, and implement the target hook in the ARM backend disable the transforms in question.
Fixes https://bugs.llvm.org/show_bug.cgi?id=38530 . (I don't have a reduced testcase for that bug. But we should have sufficient test coverage for PerformSHLSimplify given that we're not playing weird tricks with the worklist. I can try to bugpoint it if necessary, though.)
Differential Revision: https://reviews.llvm.org/D50667
This should fix a possible hang when compiling sys/dev/nxge/if_nxge.c (which exists now only in the stable/11 branch) for arm.
show more ...
|
|
Revision tags: release/12.0.0 |
|
| #
12da6be5 |
| 08-Nov-2018 |
Kyle Evans <[email protected]> |
MFC r340146: Move pmc* bits behind MK_PMC to fix WITHOUT_PMC build
Approved by: re (rgrimes)
|
| #
3b915697 |
| 14-Sep-2018 |
Matt Macy <[email protected]> |
re-enable pmcstat, pmccontrol, and pmcannotate for gcc4 builds
I had disabled building of the aforementioned targets due to warnings breaking tinderbox. This silences the warning and restores them t
re-enable pmcstat, pmccontrol, and pmcannotate for gcc4 builds
I had disabled building of the aforementioned targets due to warnings breaking tinderbox. This silences the warning and restores them to the build.
Reported by: jhibbits Reviewed by: jhibbits Approved by: re (gjb)
show more ...
|
| #
7920ad94 |
| 18-Aug-2018 |
Kyle Evans <[email protected]> |
libbe(3): Move build goop back out of cddl/
Some background: in the GSoC project, libbe/Makefile lived in lib/libbe. I created projects/bectl branch, maintained the above for all of five minutes bef
libbe(3): Move build goop back out of cddl/
Some background: in the GSoC project, libbe/Makefile lived in lib/libbe. I created projects/bectl branch, maintained the above for all of five minutes before I misread Makefile.inc1 and decided that it couldn't possibly build outside of cddl/, so I kicked the Makefile out into the cddl/ build and all was good. The misreading was of the bit where .WAIT is added to SUBDIR after lib, libexec but prior to building bin and cddl *only during the install targets*, which is the critical part.
Fast forward- buildworld was still broken in my branch unbeknownst to me because I didn't nuke my OBJDIR. Combing through Makefile.inc1 eventually revealed the necessary magic to make sure that libbe's dependencies are specified well enough, and it becomes clear what needs done to make a non-cddl/ build work. This is an interesting prospect, because the build split is kind of annoying to work with.
IGNORE_PRAGMA is added to avoid dropping WARNS by one more. This was previously pulled in via cddl/Makefile.inc.
show more ...
|
| #
71cb2dfc |
| 17-Jul-2018 |
Warner Losh <[email protected]> |
Remove special cases for armeb in the build.
Differential Revision: https://reviews.freebsd.org/D16257
|
| #
e4b0a90e |
| 25-Jun-2018 |
Brooks Davis <[email protected]> |
Normalize the g(eom,cache,part,...) build.
Rather then combining hardlink creation for the geom(8) binary with shared library build, move libraries to src/lib/geom so they are built and installed no
Normalize the g(eom,cache,part,...) build.
Rather then combining hardlink creation for the geom(8) binary with shared library build, move libraries to src/lib/geom so they are built and installed normally. Create a common Makefile.classes which is included by both lib/geom/Makefile and sbin/geom/Makefile so the symlink and libraries stay in sync.
The relocation of libraries allows libraries to be build for 32-bit compat. This also reduces the number of non-standard builds in the system.
This commit is not sufficent to run a 32-bit /sbin/geom on a 64-bit system out of the box as it will look in the wrong place for libraries unless GEOM_LIBRARY_PATH is set appropriatly in the environment.
Reviewed by: bdrewery Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D15360
show more ...
|
|
Revision tags: release/11.2.0 |
|
| #
f39bffc6 |
| 16-Jun-2018 |
Konstantin Belousov <[email protected]> |
Rework ofed build.
Aligns the build with the FreeBSD traditional approach to not build in contrib/, and to track inter-dependencies between libraries.
With help from: bdrewery Reviewed by: bdrewery
Rework ofed build.
Aligns the build with the FreeBSD traditional approach to not build in contrib/, and to track inter-dependencies between libraries.
With help from: bdrewery Reviewed by: bdrewery, hselasky Sponsored by: Mellanox Technologies MFC after: 2 weeks Differential revision: https://reviews.freebsd.org/D15648
show more ...
|
| #
456eeabe |
| 09-Jun-2018 |
Matt Macy <[email protected]> |
pmc: fix logic in skipping riscv
|
| #
6159b91c |
| 09-Jun-2018 |
Matt Macy <[email protected]> |
pmc: don't build on riscv where there's no kmod support
|
| #
f992dd4b |
| 07-Jun-2018 |
Matt Macy <[email protected]> |
pmc: convert native to jsonl and track TSC value of samples
- add '-j' options to filter to enable converting native pmc log format to json lines format to enable the use of scripts and external
pmc: convert native to jsonl and track TSC value of samples
- add '-j' options to filter to enable converting native pmc log format to json lines format to enable the use of scripts and external tooling
% pmc filter -j pmc.log pmc.jsonl
- Record the tsc value in sampling interrupts as opposed to recording nanotime when the sample is copied to a global log in hardclock - potentially many milliseconds later.
- At initialize record the tsc_freq and the time of day to give us an offset for translating the tsc values in callchain records
show more ...
|
| #
cde6fa28 |
| 04-Apr-2018 |
Ruslan Bukin <[email protected]> |
Add new shared library -- libopencsd.
OpenCSD is an ARM CoreSight(tm) trace packets decoder.
- Connect libopencsd to the arm64 build. - Install opencsd headers to /usr/include/opencsd/
Sponsored b
Add new shared library -- libopencsd.
OpenCSD is an ARM CoreSight(tm) trace packets decoder.
- Connect libopencsd to the arm64 build. - Install opencsd headers to /usr/include/opencsd/
Sponsored by: DARPA, AFRL
show more ...
|
| #
30b3274f |
| 21-Mar-2018 |
Ruslan Bukin <[email protected]> |
Add new shared library -- libipt.
libipt is the Intel Processor Trace (Intel PT) packets decoder.
- Include libipt to amd64 build. - Install libipt headers to /usr/include/libipt/
Sponsored by: DA
Add new shared library -- libipt.
libipt is the Intel Processor Trace (Intel PT) packets decoder.
- Include libipt to amd64 build. - Install libipt headers to /usr/include/libipt/
Sponsored by: DARPA, AFRL
show more ...
|
| #
b37f6c98 |
| 22-Jan-2018 |
Kyle Evans <[email protected]> |
Add libregex, connect it to the build
libregex is a regex(3) implementation intended to feature GNU extensions and any other non-POSIX compliant extensions that are deemed worthy.
These extensions
Add libregex, connect it to the build
libregex is a regex(3) implementation intended to feature GNU extensions and any other non-POSIX compliant extensions that are deemed worthy.
These extensions are separated out into a separate library for the sake of not cluttering up libc further with them as well as not deteriorating the speed (or lack thereof) of the libc implementation.
libregex is implemented as a build of the libc implementation with LIBREGEX defined to distinguish this from a libc build. The reasons for implementation like this are two-fold:
1.) Maintenance- This reduces the overhead induced by adding yet another regex implementation to base.
2.) Ease of use- Flipping on GNU extensions will be as simple as linking against libregex, and POSIX-compliant compilations can be guaranteed with a REG_POSIX cflag that should be ignored by libc/regex and disables extensions in libregex. It is also easier to keep REG_POSIX sane and POSIX pure when implemented in this fashion.
Tests are added for future functionality, but left disconnected for the time being while other testing is done.
Reviewed by: cem (previous version) Differential Revision: https://reviews.freebsd.org/D12934
show more ...
|
| #
5f8eed2f |
| 20-Nov-2017 |
Ed Maste <[email protected]> |
Install strings unconditionally
Previously it was enabled by WITH_/WITHOUT_TOOLCHAIN, but it is commonly expected to be available and may have non-toolchain consumers. As it is now taken from the B
Install strings unconditionally
Previously it was enabled by WITH_/WITHOUT_TOOLCHAIN, but it is commonly expected to be available and may have non-toolchain consumers. As it is now taken from the BSD-licensed ELF Tool Chain project, just install it unconditionally.
PR: 213665, 223725 Reviewed by: bdrewery MFC after: 1 month Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D8398
show more ...
|
| #
653667f9 |
| 09-Nov-2017 |
Baptiste Daroussin <[email protected]> |
import zstd 1.3.2
|
| #
82fcadcd |
| 31-Oct-2017 |
Bryan Drewery <[email protected]> |
Connect libpathconv, disconnected since import in r309035.
Sponsored by: Dell EMC Isilon
|
| #
ceb36bc9 |
| 28-Oct-2017 |
Mariusz Zaborski <[email protected]> |
Introduce caspermocks.
The idea behinds mocks is that we don't need to ifdef a lot of code in tools itself but those defines are hidden in the casper library. Right now the mocks are implemented as
Introduce caspermocks.
The idea behinds mocks is that we don't need to ifdef a lot of code in tools itself but those defines are hidden in the casper library. Right now the mocks are implemented as define/inlines functions. There was a very long discussion how this should be implemented. This approach has some advantages like we don't need to link to any additional libraries. Unfortunately there are also some disadvantages for example it is easy to get library out of sync between two versions of functions or that we need extra define to compile program with casper support. This isn't an ideal solution but it's good enough for now and should simplify capsicumizing programs. This also doesn't close us any other ways to do those mocks and this should evolve in time.
Discussed with: pjd, emaste, ed, rwatson, bapt, cem, bdrewery Differential Revision: https://reviews.freebsd.org/D8753
show more ...
|
| #
d27927f7 |
| 24-Oct-2017 |
Ruslan Bukin <[email protected]> |
Extract a set of pmcstat functions and interfaces to the new internal library -- libpmcstat.
This includes PMC logging module, symbols lookup functions, ELF parsing, process management, PMC attachme
Extract a set of pmcstat functions and interfaces to the new internal library -- libpmcstat.
This includes PMC logging module, symbols lookup functions, ELF parsing, process management, PMC attachment, etc.
This allows to reuse code while building new hwpmc(4)-based applications.
Also add pmcstat_symbol_search_by_name() function that allows to find mapped IP range for a given function name.
Reviewed by: kib Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D12718
show more ...
|
| #
fc203cd4 |
| 21-Oct-2017 |
Dimitry Andric <[email protected]> |
After the import of libc++ 5.0.0, there is no need to disable building libc++experimental.a on arm (r318654) and mips (r318859) anymore, since upstream fixed the static assertions which would occur.
After the import of libc++ 5.0.0, there is no need to disable building libc++experimental.a on arm (r318654) and mips (r318859) anymore, since upstream fixed the static assertions which would occur.
Noticed by: George Abdelmalik <[email protected]> PR: 223119 MFC after: 3 days
show more ...
|
| #
c8550231 |
| 09-Oct-2017 |
Warner Losh <[email protected]> |
Disconnect libstand from the build.
Remove libstand from the src/lib build. Remove LIBSTAND from bsd.libnames.mk. Add affected files to the obsolete files list.
Sponsored by: Netflix
|