Changes in __config

b5893f02 - Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp

Fri, 12 Apr 2019 20:03:27 +0000

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'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'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's usage output. They'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: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 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: 'template lldb_private::MemoryRegionInfos::MemoryRegionInfos(_InputIterator, _InputIterator, const allocator_type&)' inherited from 'std::__1::vector' using std::vector::vector; ^~~~~~/workspace/src/contrib/llvm/tools/lldb/include/lldb/Target/MemoryRegionInfo.h:128:54: error: conflicts with version inherited from 'std::__1::vector'Reported by: CIMFC 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/D58649Pull 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/D58821These 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 theconstraint, which lead to "Assertion failed: (isInt() && "Invalidaccessor"), function getInt".In case of math/secp256k1, a very large integer value was used as inputfor the constraint, which lead to "error: value '4624529908474429119'out of range for constraint 'n'".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'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 ("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/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'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&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 => 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/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'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/D59680This should fix "Assertion failed: (LiveCPSR && "CPSR liveness trackingis wrong!"), function UpdateCPSRUse" errors when building the devel/xwpeport for armv7.PR: 236062, 236568 List of files: /freebsd-12.1/contrib/libc++/include/__config

4ba319b5 - Merge clang 7.0.1 and several follow-up changes

Sat, 16 Feb 2019 15:43:49 +0000

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: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'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/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'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 'cbrtl_powl' and the trig_test test case 'reduction'.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'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/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/contrib/libc++/include/__config

b1c1e77a - Pull in r292833 from upstream libc++ trunk (by Eric Fiselier):

Mon, 23 Jan 2017 23:20:00 +0000

Pull in r292833 from upstream libc++ trunk (by Eric Fiselier): Manually force the use of __decltype in C++03 with Clang 3.4. uses `decltype` in a way incompatible with `__typeof__`. This is problematic when compiling with Clang 3.4 because even though it provides `__decltype` libc++ still used `__typeof__` because clang 3.4 doesn't provide __is_identifier which libc++ uses to detect __decltype. This patch manually detects Clang 3.4 and properly configures for it.This allows the graphics/openshadinglanguage port to build withlang/clang34.PR: 216054 List of files: /freebsd-12.1/contrib/libc++/include/__config

faaf0c6e - Pull in r255683 from upstream libc++ trunk (by Eric Fiselier):

Sun, 27 Mar 2016 21:20:43 +0000

Pull in r255683 from upstream libc++ trunk (by Eric Fiselier): [libcxx] Enable noexcept for GCC 4.6 and greater Summary: This patch allows GCC 4.6 and above to use `noexcept` as opposed to `throw()`. Is it an ABI safe change to suddenly switch on `noexcept`? I imagine it must be because it's disabled in w/ clang in C++03 but not C++11. Reviewers: danalbert, jroelofs, mclow.lists Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D15516This should fix errors from gcc 4.6 and higher when compiling llvm-covand/or other llvm tools.Reported by: bdrewery List of files: /freebsd-12.1/contrib/libc++/include/__config

91325990 - Pull in r250279 from upstream libc++ trunk (by Eric Fiselier):

Fri, 11 Mar 2016 22:56:16 +0000

Pull in r250279 from upstream libc++ trunk (by Eric Fiselier): Fix GCC atomic implementation in C++03Pull in r250802 from upstream libc++ trunk (by Eric Fiselier): Detect relaxed constexpr rules for gcc versionsPull in r255585 from upstream libc++ trunk (by Eric Fiselier): Fix various GCC mis-configurations for newer versions. This patch goes through and enables C++11 and C++14 features for newer GCC's. The main changes are: 1. Turn on variable templates. (Uses __cpp_variable_templates) 2. Assert atomic is trivially copyable (Uses _GNUC_VER >= 501). 3. Turn on trailing return support for GCC. (Uses _GNUC_VER >= 404) 4. XFAIL void_t test for GCC 5.1 and 5.2. Fixed in GCC 6.Together, these should fix building clang 3.8.0 as part of buildingworld with recent versions of gcc (e.g. the devel/*-xtoolchain-gccports). List of files: /freebsd-12.1/contrib/libc++/include/__config

78433c77 - Import patch from libc++ r197313 which allows using libc++ headers with gcc

Mon, 13 Oct 2014 22:30:08 +0000

Import patch from libc++ r197313 which allows using libc++ headers with gccDifferential Revision: https://reviews.freebsd.org/D942Reviewed by: imp List of files: /freebsd-12.1/contrib/libc++/include/__config

eed07a2e - An ABI incompatibility crept into the libc++ 3.4 import in r261283. It

Wed, 12 Feb 2014 18:14:49 +0000

An ABI incompatibility crept into the libc++ 3.4 import in r261283. Itwas caused by upstream libc++ commit r194536, which aimed to make theheaders more standards-compliant, by making std::pair's copy constructortrivial. Unfortunately, this could cause certain C++ applications usingshared libraries built against the previous version of libc++ to crash.Fix the ABI incompatibility by making std::pair's copy constructornon-trivial again.Please note: Any C++ applications or shared libraries built with libc++between r261283 and this revision should be recompiled.Reported by: stefanfMFC after: 3 weeksX-MFC-With: r261283 List of files: /freebsd-12.1/contrib/libc++/include/__config

5f5f8832 - Pull in r168610 from upstream libc++:

Mon, 26 Nov 2012 21:32:31 +0000

Pull in r168610 from upstream libc++: When using libc++ headers on FreeBSD, in combination with -std=c++98, -ansi or -std=c++03, the long long type is not supported. So in this case, several functions and types, like lldiv_t, strtoll(), are not declared.This should make it possible to use the libc++ headers in c++98 mode.Note: libc++ is originally designed as a c++0x or higher library, so youshould still take care when using it with c++98 or c++03.Noted by: Yamaya Takashi MFC after: 1 week List of files: /freebsd-12.1/contrib/libc++/include/__config