<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in Makefile</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>f5e04876 - MFC r345203,r345205,r345353,r345645,r345708,r345709,r345735,r345770,r346081,r346270,r346574,r346576:</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/lib/libc++/Makefile#f5e04876</link>
        <description>MFC r345203,r345205,r345353,r345645,r345708,r345709,r345735,r345770,r346081,r346270,r346574,r346576:r345203:Initial googlemock/googletest integration into the build/FreeBSD test suiteThis initial integration takes googlemock/googletest release 1.8.1, integratesthe library, tests, and sample unit tests into the build.googlemock/googletest&apos;s inclusion is optionally available via `MK_GOOGLETEST`.`MK_GOOGLETEST` is dependent on `MK_TESTS` and is enabled by default whenbuilt with a C++11 capable toolchain.Google tests can be specified via the `GTESTS` variable, which, in comparisonwith the other test drivers, is more simplified/streamlined, as Googletest onlysupports 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 theGoogletest [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, butwill 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 suiteThis change integrates the unit tests for zfsd into the test suite using theintegration method described in r345203.This change removes the `LOCALBASE` includes added for the port version ofgooglemock/googletest, as well as unnecessary `LIBADD`/`DPADD` and `CXXFLAGS`defines, which are included in the `GTEST_CXXFLAGS` variable, as part ofr345203.r345353 (by asomers):googletest: backport GTEST_SKIP to googletest 1.8.1This commit backports revisions 00938b2b228f3b70d3d9e51f29a1505bdad43f1e and59f90a338bce2376b540ee239cf4e269bf6d68ad from googletest&apos;s master branch toour included version of googletest, which is based on 1.8.1. It adds theGTEST_SKIP feature, which is very useful for a project like FreeBSD wheresome tests depend on particular system configurations.Obtained from:	github.com/google/googletestr345645:Spam CXXFLAGS with `-I${DESTDIR}/usr/include/private`, instead of GTEST_CXXFLAGSThis makes it easier for googletest users to leverage googletest, instead offorcing them to plug GTEST_CXXFLAGS into CXXFLAGS manually (resulting inunnecessary duplication).I will be following this up with a more proper fix in src.libnames.mk, assrc.libnames.mk should be automatically adding this directory toCFLAGS/CXXFLAGS when private libraries are referenced. Not doing so can resultin mismatches between base-provided private library&apos;s and ports-providedlibrary&apos;s headers.While here, tweak the comment to clarify what the intent is behind spammingCXXFLAGS.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 togoogletest.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 twomost used C++ compilers on FreeBSD (clang++ and g++) support both modes, it islikely to work with both toolchains. This method will be refined in the futureto support more variants of C++, as not all versions of clang++ and g++ (forinstance) 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:	yesTested with:	make tinderboxr345709:Allow users to override CSTD/CXXSTD on a per-prog basisThe current logic for CSTD/CXXSTD requires homogenity as far as thesupported C/C++ standards, which is a sensible default. However, whendealing with differing versions of C++, some code may compile with C++11, butnot C++17 (for instance). So in order to avoid having people convert over theircode to the new standard, give the users the ability to specify the standard ona per-program basis.This will allow a user to override the supporting standard for a set ofprograms, mixing C++11 with C++14 (for instance).Apprved by:	emaste (mentor)r345735:Allow programs to set `NO_SHARED` on a per-PROG basisThis is particularly useful when installing programs for tests that need to belinked statically, e.g., mini-me from capsicum-test, which is linked staticallyto 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 &lt;yaneurabeya@gmail.com&gt;```The goal with my merging in this change is to avoid requiring extensiverefactoring/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 upstreamproject due to the fact that the upstream project is undergoing a potentialdevelopment freeze and the maintainers aren&apos;t responding to my PR.1. https://github.com/google/googletest/pull/2203r346081 (by trasz):Make zfsd(8) build obey CFLAGS.Obtained from:	CheriBSDr346270 (by trasz):Drop -g from CFLAGS for zfsd(8).  No idea why it was ever there.r346574:Rework CXXSTD setting via r345708This change allows the user to once again override the C++ standard, restoringhigh-level pre-r345708 behavior.This also unbreaks building lib/ofed/libibnetdisc/Makefile with a non-C++11capable compiler, e.g., g++ 4.2.1, as the library supported being built witholder C++ standards.r346576:Fix up CXXSTD support originally added in r345708r345708 worked for the base system, but unfortunately, caused a lot ofdisruption for third-party packages that relied on C++, since bsd.sys.mk isused by applications outside the base system. The defaults picked didn&apos;t matchthe compiler&apos;s defaults and broke some builds that didn&apos;t specify a standard,as well as some that overrode the value by setting `-std=gnu++14` (forexample) manually.This change takes a more relaxed approach to appending `-std=${CXXSTD}` toCXXFLAGS, by only doing so when the value is specified, as opposed tooverriding the standard set by an end-user. This avoids the need for havingto bake NOP default into bsd.sys.mk for supported compiler-toolchainversions.In order to make this change possible, add CXXSTD to Makefile snippets whichrelied on the default value (c++11) added in r345708.

            List of files:
            /freebsd-12.1/lib/libc++/Makefile</description>
        <pubDate>Thu, 23 May 2019 01:09:10 +0000</pubDate>
        <dc:creator>Enji Cooper &lt;ngie@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>df407fbc - Revert r348136</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/lib/libc++/Makefile#df407fbc</link>
        <description>Revert r348136I accidentally committed some unrelated local changes to`.../tests/sys/opencrypto` along with this MFC set.

            List of files:
            /freebsd-12.1/lib/libc++/Makefile</description>
        <pubDate>Thu, 23 May 2019 00:59:05 +0000</pubDate>
        <dc:creator>Enji Cooper &lt;ngie@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>e787ffab - MFC r345203,r345205,r345353,r345645,r345708,r345709,r345735,r345770,r346574,r346576:</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/lib/libc++/Makefile#e787ffab</link>
        <description>MFC r345203,r345205,r345353,r345645,r345708,r345709,r345735,r345770,r346574,r346576:r345203:Initial googlemock/googletest integration into the build/FreeBSD test suiteThis initial integration takes googlemock/googletest release 1.8.1, integratesthe library, tests, and sample unit tests into the build.googlemock/googletest&apos;s inclusion is optionally available via `MK_GOOGLETEST`.`MK_GOOGLETEST` is dependent on `MK_TESTS` and is enabled by default whenbuilt with a C++11 capable toolchain.Google tests can be specified via the `GTESTS` variable, which, in comparisonwith the other test drivers, is more simplified/streamlined, as Googletest onlysupports 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 theGoogletest [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, butwill 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 suiteThis change integrates the unit tests for zfsd into the test suite using theintegration method described in r345203.This change removes the `LOCALBASE` includes added for the port version ofgooglemock/googletest, as well as unnecessary `LIBADD`/`DPADD` and `CXXFLAGS`defines, which are included in the `GTEST_CXXFLAGS` variable, as part ofr345203.r345353 (by asomers):googletest: backport GTEST_SKIP to googletest 1.8.1This commit backports revisions 00938b2b228f3b70d3d9e51f29a1505bdad43f1e and59f90a338bce2376b540ee239cf4e269bf6d68ad from googletest&apos;s master branch toour included version of googletest, which is based on 1.8.1. It adds theGTEST_SKIP feature, which is very useful for a project like FreeBSD wheresome tests depend on particular system configurations.Obtained from:	github.com/google/googletestr345645:Spam CXXFLAGS with `-I${DESTDIR}/usr/include/private`, instead of GTEST_CXXFLAGSThis makes it easier for googletest users to leverage googletest, instead offorcing them to plug GTEST_CXXFLAGS into CXXFLAGS manually (resulting inunnecessary duplication).I will be following this up with a more proper fix in src.libnames.mk, assrc.libnames.mk should be automatically adding this directory toCFLAGS/CXXFLAGS when private libraries are referenced. Not doing so can resultin mismatches between base-provided private library&apos;s and ports-providedlibrary&apos;s headers.While here, tweak the comment to clarify what the intent is behind spammingCXXFLAGS.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 togoogletest.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 twomost used C++ compilers on FreeBSD (clang++ and g++) support both modes, it islikely to work with both toolchains. This method will be refined in the futureto support more variants of C++, as not all versions of clang++ and g++ (forinstance) 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:	yesTested with:	make tinderboxr345709:Allow users to override CSTD/CXXSTD on a per-prog basisThe current logic for CSTD/CXXSTD requires homogenity as far as thesupported C/C++ standards, which is a sensible default. However, whendealing with differing versions of C++, some code may compile with C++11, butnot C++17 (for instance). So in order to avoid having people convert over theircode to the new standard, give the users the ability to specify the standard ona per-program basis.This will allow a user to override the supporting standard for a set ofprograms, mixing C++11 with C++14 (for instance).Approved by:	emaste (mentor)r345735:Allow programs to set `NO_SHARED` on a per-PROG basisThis is particularly useful when installing programs for tests that need to belinked statically, e.g., mini-me from capsicum-test, which is linked staticallyto 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 &lt;yaneurabeya@gmail.com&gt;```The goal with my merging in this change is to avoid requiring extensiverefactoring/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 upstreamproject due to the fact that the upstream project is undergoing a potentialdevelopment freeze and the maintainers aren&apos;t responding to my PR.1. https://github.com/google/googletest/pull/2203r346574:Rework CXXSTD setting via r345708This change allows the user to once again override the C++ standard, restoringhigh-level pre-r345708 behavior.This also unbreaks building lib/ofed/libibnetdisc/Makefile with a non-C++11capable compiler, e.g., g++ 4.2.1, as the library supported being built witholder C++ standards.r346576:Fix up CXXSTD support originally added in r345708r345708 worked for the base system, but unfortunately, caused a lot ofdisruption for third-party packages that relied on C++, since bsd.sys.mk isused by applications outside the base system. The defaults picked didn&apos;t matchthe compiler&apos;s defaults and broke some builds that didn&apos;t specify a standard,as well as some that overrode the value by setting `-std=gnu++14` (forexample) manually.This change takes a more relaxed approach to appending `-std=${CXXSTD}` toCXXFLAGS, by only doing so when the value is specified, as opposed tooverriding the standard set by an end-user. This avoids the need for havingto bake NOP default into bsd.sys.mk for supported compiler-toolchainversions.In order to make this change possible, add CXXSTD to Makefile snippets whichrelied on the default value (c++11) added in r345708.

            List of files:
            /freebsd-12.1/lib/libc++/Makefile</description>
        <pubDate>Thu, 23 May 2019 00:55:28 +0000</pubDate>
        <dc:creator>Enji Cooper &lt;ngie@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>b5893f02 - Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/lib/libc++/Makefile#b5893f02</link>
        <description>Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp8.0.0 final release r356365.MFC r340287 (by emaste):Consolidate gcov entries in OptionalObsoleteFilesSponsored by:	The FreeBSD FoundationMFC 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, markjSponsored by:	The FreeBSD FoundationDifferential Revision:	https://reviews.freebsd.org/D17923MFC r340296 (by emaste):Move llvm-profdata build into MK_LLVM_COV blockllvm-profdata is used with llvm-cov for code coverage (although llvm-covcan also operate independently in a gcov-compatible mode).Although llvm-profdata can be used independently of llvm-cov it makessense to group these under one option.Also handle these in OptionalObsoleteFiles.inc while here.Sponsored by:	The FreeBSD FoundationMFC r340300 (by emaste):libllvm: Move SampleProfWriter to SRCS_MINIt is required by llvm-profdata, now built by default under theLLVM_COV knob.  The additional complexity that would come from avoidingbuilding it if CLANG_EXTRAS and LLVM_COV are both disabled is not worththe small savings in build time.Sponsored by:	The FreeBSD FoundationMFC r340972 (by emaste):llvm-objdump: initial man pageBased on llvm-objdump&apos;s online documentation and usage information.This serves as a starting point; additional detail and cleanup stillrequired.Also being submitted upstream in LLVM review D54864.  I expect to usethis bespoke copy while we have LLVM 6.0 or 7.0 in FreeBSD; when weupdate to LLVM 8.0 it should be upstream and we will switch to it.PR:		233437Reviewed by:	bcr (man formatting)Sponsored by:	The FreeBSD FoundationDifferential Revision:	https://reviews.freebsd.org/D18309MFC r340973 (by emaste):llvm-objdump.1: remove invalid optionsSome options appear in llvm-objdump&apos;s usage information as a side effectof its option parsing implementation and are not actually llvm-objdumpoptions.  Reported in LLVM review https://reviews.llvm.org/D54864.Reported by:	Fangrui SongSponsored by:	The FreeBSD FoundationMFC r340975 (by emaste):llvm-objdump.1: fix igor / mandoc -Tlint warningsAccidentally omitted from r340972.MFC r341055 (by emaste):llvm-objdump.1: remove more unintentional optionsSome options come from static constructors in LLVM libraries and areautomatically added to llvm&apos;s usage output.  They&apos;re not really supposedto be llvm-objdump options.Reported by:	Fangrui Song in LLVM review D54864Sponsored by:	The FreeBSD FoundationMFC r344779:Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ tothe upstream release_80 branch r355313 (effectively, 8.0.0 rc3).  Therelease will follow very soon, but no more functional changes areexpected.Release notes for llvm, clang and lld 8.0.0 will soon be available here:&lt;https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html&gt;&lt;https://releases.llvm.org/8.0.0/tools/clang/docs/ReleaseNotes.html&gt;&lt;https://releases.llvm.org/8.0.0/tools/lld/docs/ReleaseNotes.html&gt;PR:		236062Relnotes:	yesMFC r344798 (by emaste):libllvm: promote WithColor and xxhash to SRCS_MINThe armv6 build failed in CI due to missing symbols (from these twosource files) in the bootstrap Clang.This affected only armv6 because other Clang-using archs are using LLDas the bootstrap linker, and thus include SRCS_MIW via LLD_BOOTSTRAP.Reported by:	CI, via lwhsuSponsored by:	The FreeBSD FoundationMFC r344825:Add a few missed files to the MK_LLVM_TARGET_BPF=yes case, otherwiseclang and various other executables will fail to link with undefinedsymbols.Reported by:	O. Hartmann &lt;ohartmann@walstatt.org&gt;MFC r344852:Put in a temporary workaround for what is likely a gcc 6 bug (it doesnot occur with gcc 7 or later).  This should prevent the following errorfrom 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: &apos;template&lt;class _InputIterator&gt; lldb_private::MemoryRegionInfos::MemoryRegionInfos(_InputIterator, _InputIterator, const allocator_type&amp;)&apos; inherited from &apos;std::__1::vector&lt;lldb_private::MemoryRegionInfo&gt;&apos;   using std::vector&lt;lldb_private::MemoryRegionInfo&gt;::vector;                                                      ^~~~~~/workspace/src/contrib/llvm/tools/lldb/include/lldb/Target/MemoryRegionInfo.h:128:54: error: conflicts with version inherited from &apos;std::__1::vector&lt;lldb_private::MemoryRegionInfo&gt;&apos;Reported by:	CIMFC r344896:Pull in r354937 from upstream clang trunk (by J&#246;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/D58649Pull in r355491 from upstream clang trunk (by Hans Wennborg):  Inline asm constraints: allow ICE-like pointers for the &quot;n&quot;  constraint (PR40890)  Apparently GCC allows this, and there&apos;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/D58821These should fix assertions and errors when using the inline assembly&quot;n&quot; constraint in certain ways.In case of devel/valgrind, a pointer was used as the input for theconstraint, which lead to &quot;Assertion failed: (isInt() &amp;&amp; &quot;Invalidaccessor&quot;), function getInt&quot;.In case of math/secp256k1, a very large integer value was used as inputfor the constraint, which lead to &quot;error: value &apos;4624529908474429119&apos;out of range for constraint &apos;n&apos;&quot;.PR:             236216, 236194MFC r344951:Merge llvm, clang, compiler-rt, libc++, lld, and lldb release_80 branchr355677 (effectively, 8.0.0 rc4), resolve conflicts, and bump versionnumbers.PR:		236062MFC r345018:Merge LLVM libunwind trunk r351319, from just before upstream&apos;srelease_80 branch point.  Afterwards, we will merge the rest of thechanges in the actual release_80 branch.PR:		236062MFC r345019:Merge LLVM libunwind release_80 branch r355677 (effectively, 8.0.0 rc4).PR:		236062MFC 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 (&quot;excessive  compile time building opencollada&quot;), 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/D59201This should fix a hang when compiling certain generated .cpp files inthe graphics/opencollada port.PR:		236313MFC r345068 (by jhb):Move libunwind out of contrib/llvm/projects.Move LLVM&apos;s libunwind to its own contrib/ directory similar to otherruntime libraries like libc++ and libcxxrt.Reviewed by:	dim, emasteDifferential Revision:	https://reviews.freebsd.org/D19534MFC r345073:Revert r308867 (which was originally committed in the clang390-importproject 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 tothe most recent version, the above workaround is no longer needed.  Theupstream commit which fixed this is:  https://llvm.org/viewvc/llvm-project?view=revision&amp;revision=292723Specifically, 32 bit (i386-freebsd) executables optimized with omittedframe pointers and Call Frame Optimization should now behave correctlywhen a C++ exception is thrown, and the stack is unwound.Upstream PR:	https://llvm.org/bugs/show_bug.cgi?id=30879PR:		236062MFC r345152:Merge llvm, clang, compiler-rt, libc++, libunwind, lld, and lldbrelease_80 branch r356034 (effectively, 8.0.0 rc5), resolve conflicts,and bump version numbers.PR:		236062MFC 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 forthat will come in a follow-up commit.PR:		236062MFC r345232:Bootstrap svn:mergeinfo on contrib/openmp.PR:		236062MFC r345233:Merge openmp release_80 branch r356034 (effectively, 8.0.0 rc5).PR:		236062MFC r345234:Add openmp __kmp_gettid() wrapper, using pthread_getthreadid_np(3).This has also been submitted upstream.PR:           236062MFC r345283:Enable building libomp.so for 32-bit x86.  This is done by selectivelyenabling the functions that save and restore MXCSR, since access to thisregister 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, 236582MFC r345345:Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp8.0.0 final release r356365.  There were no functional changes since themost 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.htmlhttps://llvm.org/releases/8.0.0/tools/clang/docs/ReleaseNotes.htmlhttps://llvm.org/releases/8.0.0/tools/lld/docs/ReleaseNotes.htmlhttps://llvm.org/releases/8.0.0/projects/libcxx/docs/ReleaseNotes.htmlPR:		236062MFC 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/D57385Pull 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 =&gt; a.so (not linked with -z defs)      void f(); // f is undefined      void g() { f(); }      // b.cc =&gt; 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/D57569Together, these add support for --no-allow-shlib-undefined, and make itthe default for executables, so they will fail to link if any symbolsfrom needed shared libraries are undefined.Reported by:	jbeichPR:		236062, 236141MFC r345449:Pull in r356809 from upstream llvm trunk (by Eli Friedman):  [ARM] Don&apos;t form &quot;ands&quot; when it isn&apos;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/D59680This should fix &quot;Assertion failed: (LiveCPSR &amp;&amp; &quot;CPSR liveness trackingis wrong!&quot;), function UpdateCPSRUse&quot; errors when building the devel/xwpeport for armv7.PR:		236062, 236568

            List of files:
            /freebsd-12.1/lib/libc++/Makefile</description>
        <pubDate>Fri, 12 Apr 2019 20:03:27 +0000</pubDate>
        <dc:creator>Dimitry Andric &lt;dim@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>4ba319b5 - Merge clang 7.0.1 and several follow-up changes</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/lib/libc++/Makefile#4ba319b5</link>
        <description>Merge clang 7.0.1 and several follow-up changesMFC r341825:Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ tothe upstream release_70 branch r348686 (effectively, 7.0.1 rc3).  Therelease will follow very soon, but no more functional changes areexpected.Release notes for llvm, clang and lld 7.0.0 are available here:&lt;http://releases.llvm.org/7.0.0/docs/ReleaseNotes.html&gt;&lt;http://releases.llvm.org/7.0.0/tools/clang/docs/ReleaseNotes.html&gt;&lt;http://releases.llvm.org/7.0.0/tools/lld/docs/ReleaseNotes.html&gt;PR:		230240, 230355Relnotes:	yesMFC r342123:Update clang, llvm, lld, lldb, compiler-rt and libc++ version number to7.0.1 release r349250.  There were no functional changes since the 7.0.1rc3 import.PR:		230240, 230355Relnotes:	yesr343429 | emaste | 2019-01-25 15:46:13 +0100 (Fri, 25 Jan 2019) | 16 linesclang: default to DWARF 4 as of FreeBSD 13FreeBSD previously defaulted to DWARF 2 because several tools (gdb,ctfconvert, etc.) did not support later versions.  These have eitherbeen 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 kernelbuild sets the DWARF version explicitly via -gdwarf2, so this shouldhave no effect there.PR:		234887 [exp-run]Reviewed by:	markjSponsored by:	The FreeBSD FoundationDifferential Revision:	https://reviews.freebsd.org/D17930MFC 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&apos;t currently map these constraints to physical register numbers  so they don&apos;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&apos;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/D57641Pull 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&apos;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/D57735These should fix a problem in clang 7.0 where it would sometimes emitlong double floating point instructions in a slightly wrong order,leading to failures in our libm tests.  In particular, the cbrt_testtest case &apos;cbrtl_powl&apos; and the trig_test test case &apos;reduction&apos;.Also bump __FreeBSD_cc_version, to be able to detect this in our testsuite.Reported by:    lwhsuPR:		234040Upstream PR:	https://bugs.llvm.org/show_bug.cgi?id=40206MFC 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&apos;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&apos;t have a  reduced testcase for that bug. But we should have sufficient test  coverage for PerformSHLSimplify given that we&apos;re not playing weird  tricks with the worklist. I can try to bugpoint it if necessary,  though.)  Differential Revision: https://reviews.llvm.org/D50667This should fix a possible hang when compiling sys/dev/nxge/if_nxge.c(which exists now only in the stable/11 branch) for arm.

            List of files:
            /freebsd-12.1/lib/libc++/Makefile</description>
        <pubDate>Sat, 16 Feb 2019 15:43:49 +0000</pubDate>
        <dc:creator>Dimitry Andric &lt;dim@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>5d77776c - Belatedly add variant.cpp to libc++.  This completes the support for the</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/lib/libc++/Makefile#5d77776c</link>
        <description>Belatedly add variant.cpp to libc++.  This completes the support for theupcoming C++17 std::variant template.

            List of files:
            /freebsd-12.1/lib/libc++/Makefile</description>
        <pubDate>Sun, 19 Feb 2017 14:53:59 +0000</pubDate>
        <dc:creator>Dimitry Andric &lt;dim@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>c91dd79f - Use SRCTOP-relative paths to other directories instead of .CURDIR-relative ones</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/lib/libc++/Makefile#c91dd79f</link>
        <description>Use SRCTOP-relative paths to other directories instead of .CURDIR-relative onesThis implifies pathing in make/displayed outputMFC after:    3 weeksSponsored by: Dell EMC Isilon

            List of files:
            /freebsd-12.1/lib/libc++/Makefile</description>
        <pubDate>Fri, 20 Jan 2017 03:59:10 +0000</pubDate>
        <dc:creator>Enji Cooper &lt;ngie@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>3f910b91 - Update the libc++ Makefile to be more like the other llvm and clang</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/lib/libc++/Makefile#3f910b91</link>
        <description>Update the libc++ Makefile to be more like the other llvm and clangMakefiles.

            List of files:
            /freebsd-12.1/lib/libc++/Makefile</description>
        <pubDate>Mon, 09 Jan 2017 22:46:47 +0000</pubDate>
        <dc:creator>Dimitry Andric &lt;dim@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>7b173dd6 - Add additional libc++ 4.0.0 headers.</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/lib/libc++/Makefile#7b173dd6</link>
        <description>Add additional libc++ 4.0.0 headers.

            List of files:
            /freebsd-12.1/lib/libc++/Makefile</description>
        <pubDate>Mon, 09 Jan 2017 19:37:17 +0000</pubDate>
        <dc:creator>Dimitry Andric &lt;dim@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>629582ca - Now that external gcc directly natively links to libc++ we can remove</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/lib/libc++/Makefile#629582ca</link>
        <description>Now that external gcc directly natively links to libc++ we can removethe dirty hack made to fake libstdc++

            List of files:
            /freebsd-12.1/lib/libc++/Makefile</description>
        <pubDate>Sat, 10 Dec 2016 18:29:39 +0000</pubDate>
        <dc:creator>Baptiste Daroussin &lt;bapt@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>f661dbee - GCC External: Revert r300886, r300904, r300917, r300918</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/lib/libc++/Makefile#f661dbee</link>
        <description>GCC External: Revert r300886, r300904, r300917, r300918The fix in r300873 is mostly enough.  A fix for lib32 will becommitted.separately.

            List of files:
            /freebsd-12.1/lib/libc++/Makefile</description>
        <pubDate>Sun, 29 May 2016 06:20:15 +0000</pubDate>
        <dc:creator>Bryan Drewery &lt;bdrewery@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>1766eeaf - Use a relative symlink for proper --sysroot support.</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/lib/libc++/Makefile#1766eeaf</link>
        <description>Use a relative symlink for proper --sysroot support.Sponsored by:	EMC / Isilon Storage Division

            List of files:
            /freebsd-12.1/lib/libc++/Makefile</description>
        <pubDate>Sat, 28 May 2016 16:38:09 +0000</pubDate>
        <dc:creator>Bryan Drewery &lt;bdrewery@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>ce00342b - Move external GCC compiler hacks to bsd.sys.mk.</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/lib/libc++/Makefile#ce00342b</link>
        <description>Move external GCC compiler hacks to bsd.sys.mk.This allows respecting -nostdinc, -nostdinc++ and -nostdlib beforemaking the decision to add in -isystem, etc.  The -isystem flagsare problematic for building lib/libc++ and lib/libcxxrt which wantsto only use its own headers.More information the need of these flags can be found athttps://gcc.gnu.org/ml/gcc/2016-03/msg00219.htmlThis also reverts r300873.Sponsored by:	EMC / Isilon Storage Division

            List of files:
            /freebsd-12.1/lib/libc++/Makefile</description>
        <pubDate>Fri, 27 May 2016 23:03:44 +0000</pubDate>
        <dc:creator>Bryan Drewery &lt;bdrewery@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>09210a28 - After r300770, for libc++ and libcxxrt, use -isystem instead of -I.</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/lib/libc++/Makefile#09210a28</link>
        <description>After r300770, for libc++ and libcxxrt, use -isystem instead of -I.This should fix builds with external gcc toolchains from ports, whichalso use -isystem to work around problems with gcc&apos;s --sysrootimplementation.  Thanks to Bryan Drewery for this workaround.

            List of files:
            /freebsd-12.1/lib/libc++/Makefile</description>
        <pubDate>Fri, 27 May 2016 20:45:32 +0000</pubDate>
        <dc:creator>Dimitry Andric &lt;dim@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>7533aa15 - Add missing CLEANFILES.</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/lib/libc++/Makefile#7533aa15</link>
        <description>Add missing CLEANFILES.MFC after:	1 weekSponsored by:	EMC / Isilon Storage Division

            List of files:
            /freebsd-12.1/lib/libc++/Makefile</description>
        <pubDate>Fri, 11 Mar 2016 23:45:56 +0000</pubDate>
        <dc:creator>Bryan Drewery &lt;bdrewery@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>c389411c - Remove libc, librtld_db, libthr packages, and further increase</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/lib/libc++/Makefile#c389411c</link>
        <description>Remove libc, librtld_db, libthr packages, and further increasethe constraints on what needs to be installed in a specific tomaintain consistency during upgrades.Create a new clibs package containing libraries that are neededas a bare minimum for consistency.With much help and input from:	kibSponsored by:	The FreeBSD Foundation

            List of files:
            /freebsd-12.1/lib/libc++/Makefile</description>
        <pubDate>Fri, 05 Feb 2016 21:01:08 +0000</pubDate>
        <dc:creator>Glen Barber &lt;gjb@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>a70cba95 - First pass through library packaging.</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/lib/libc++/Makefile#a70cba95</link>
        <description>First pass through library packaging.Sponsored by:	The FreeBSD Foundation

            List of files:
            /freebsd-12.1/lib/libc++/Makefile</description>
        <pubDate>Thu, 04 Feb 2016 21:16:35 +0000</pubDate>
        <dc:creator>Glen Barber &lt;gjb@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>c455b924 - Set -mlong-calls where needed to get a static clang and lldb 3.8.0</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/lib/libc++/Makefile#c455b924</link>
        <description>Set -mlong-calls where needed to get a static clang and lldb 3.8.0linking. These are too large for a branch instruction to branch from anearlier point in the code to somewhere later.This will also allow these to be build with Thumb-2 when we get thisinfrastructure.Reviewed by:	dimDifferential Revision:	https://reviews.freebsd.org/D4855

            List of files:
            /freebsd-12.1/lib/libc++/Makefile</description>
        <pubDate>Thu, 14 Jan 2016 19:00:13 +0000</pubDate>
        <dc:creator>Andrew Turner &lt;andrew@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>a9f9ec24 - Replace ln -s calls with INSTALL_SYMLINK</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/lib/libc++/Makefile#a9f9ec24</link>
        <description>Replace ln -s calls with INSTALL_SYMLINKSponsored by:	EMC / Isilon Storage Division

            List of files:
            /freebsd-12.1/lib/libc++/Makefile</description>
        <pubDate>Fri, 04 Dec 2015 03:17:14 +0000</pubDate>
        <dc:creator>Bryan Drewery &lt;bdrewery@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>3c89d6b0 - Don&apos;t override LIB*DIR variables from src.libnames.mk.</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/lib/libc++/Makefile#3c89d6b0</link>
        <description>Don&apos;t override LIB*DIR variables from src.libnames.mk.In some cases switch to the LIB*SRCDIR value.These recently were defined in r291327 and r291619.Sponsored by:	EMC / Isilon Storage Division

            List of files:
            /freebsd-12.1/lib/libc++/Makefile</description>
        <pubDate>Tue, 01 Dec 2015 22:20:04 +0000</pubDate>
        <dc:creator>Bryan Drewery &lt;bdrewery@FreeBSD.org&gt;</dc:creator>
    </item>
</channel>
</rss>
