FreeBSD src-all

More graphs

2018-06-14 14:34:05.338001335167mav

Record MFC r331046 mergeinfo, missed in r335150.
2018-05-25 08:15:55.347817333764cognet

Import CK as of commit deca119d14bfffd440770eb67cbdbeaf7b57eb7b.This is mostly a noop, for mergeinfo purpose, because the relevant changeswere committed directly.
2018-05-25 08:15:55.347817333764cognet

Import CK as of commit deca119d14bfffd440770eb67cbdbeaf7b57eb7b.This is mostly a noop, for mergeinfo purpose, because the relevant changeswere committed directly.
2018-05-25 08:15:52.622583333678des

Missed mergeinfo in previous commit.
2018-05-25 08:15:52.622583333678des

Missed mergeinfo in previous commit.
2018-05-25 08:15:42.275446333531des

Nuke auto-props.
2018-05-25 08:15:42.275446333531des

Nuke auto-props.
2018-04-14 14:36:26.37092332366kevans

MFC r316487, r316516, r316546, r316567: One big nopr316487:Allow command modifiers (fast, quiet etc.) to be stacked in any order.Add a "debug" modifier that sets rc_debug.r316516:r316487 altered the defined values of rc_force from "yes" (for yes)and NULL (for no) to "no" (for no) and no change to the definitionof yes. Two rc.d scripts, dhclient and bgfsck check rc_force foryesi, using test -n, and no, using test -z. The redefinition ofyes and no by r316487 caused rc.d/dhclient, when invoked by devdusing a devd.conf rule, to assign DHCP assigned IP addresses forinterfaces with statically assigned interfaces, breaking boot.Point of breakage was at line 25 of etc/rc.d/dhclient (r301068)where $rc_force needs to be NULL.X-MFC with: r316487r316546:Revert r316516. des@ asked that r316516 be reverted so that he can spenda little more time getting r316487 right.Requested by: des@r316567:Revert r316487. It is broken, causing boot to fail due to line 25 inetc/rc.d/dhclient unconditionally testing true when called by a devdrule during boot, ignoring statically assigned IP addresses in rc.conf.Requested by: des@
2018-04-14 14:36:26.37092332366kevans

MFC r316487, r316516, r316546, r316567: One big nopr316487:Allow command modifiers (fast, quiet etc.) to be stacked in any order.Add a "debug" modifier that sets rc_debug.r316516:r316487 altered the defined values of rc_force from "yes" (for yes)and NULL (for no) to "no" (for no) and no change to the definitionof yes. Two rc.d scripts, dhclient and bgfsck check rc_force foryesi, using test -n, and no, using test -z. The redefinition ofyes and no by r316487 caused rc.d/dhclient, when invoked by devdusing a devd.conf rule, to assign DHCP assigned IP addresses forinterfaces with statically assigned interfaces, breaking boot.Point of breakage was at line 25 of etc/rc.d/dhclient (r301068)where $rc_force needs to be NULL.X-MFC with: r316487r316546:Revert r316516. des@ asked that r316516 be reverted so that he can spenda little more time getting r316487 right.Requested by: des@r316567:Revert r316487. It is broken, causing boot to fail due to line 25 inetc/rc.d/dhclient unconditionally testing true when called by a devdrule during boot, ignoring statically assigned IP addresses in rc.conf.Requested by: des@
2018-04-07 09:25:01.540328332129kevans

Record-only MFC of r329269 and r329418r329269 was a style(9) cleanup that had a functional side-effect. r329418reverted it while benno regrouped to fight the forces of evil.
2018-04-07 09:25:01.540328332129kevans

Record-only MFC of r329269 and r329418r329269 was a style(9) cleanup that had a functional side-effect. r329418reverted it while benno regrouped to fight the forces of evil.
2018-04-05 18:15:52.316882332051kevans

Record-only MFC of r325365, r325564r325365 fixed a bug in patch(1) that would cause a match if we ran out ofcontext, say, at the beginning/end of a file. r325564 reverted it at therequest of antoine until an exp-run could be completed to fix all of theports with broken patches.r325365 was later committed as r326084, which has already been MFC'd.
2018-04-05 18:15:52.316882332051kevans

Record-only MFC of r325365, r325564r325365 fixed a bug in patch(1) that would cause a match if we ran out ofcontext, say, at the beginning/end of a file. r325564 reverted it at therequest of antoine until an exp-run could be completed to fix all of theports with broken patches.r325365 was later committed as r326084, which has already been MFC'd.
2018-03-31 10:23:33.734522331838dimstable/11/ObsoleteFiles.inc
stable/11/UPDATING
stable/11/contrib/compiler-rt/include/sanitizer/allocator_interface.h
4605 more...
Merge clang, llvm, lld, lldb, compiler-rt and libc++ 6.0.0 release, andseveral follow-up fixes.MFC r327952:Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to6.0.0 (branches/release_60 r321788). Upstream has branched for the6.0.0 release, which should be in about 6 weeks. Please report bugs andregressions, so we can get them into the release.Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11support to build; see UPDATING for more information.MFC r328010:Pull in r322473 from upstream llvm trunk (by Andrei Elovikov):[LV] Don't call recordVectorLoopValueForInductionCast fornewly-created IV from a trunc.Summary:This method is supposed to be called for IVs that have casts in theiruse-def chains that are completely ignored after vectorization underPSE. However, for truncates of such IVs the same InductionDescriptoris used during creation/widening of both original IV based on PHINodeand new IV based on TruncInst.This leads to unintended second call torecordVectorLoopValueForInductionCast with a VectorLoopVal set to thenewly created IV for a trunc and causes an assert due to attempt tostore new information for already existing entry in the map. This iswrong and should not be done.Fixes PR35773.Reviewers: dorit, Ayal, mssimpsoReviewed By: doritSubscribers: RKSimon, dim, dcaballe, hsaito, llvm-commits, hiradityaDifferential Revision: https://reviews.llvm.org/D41913This should fix "Vector value already set for part" assertions whenbuilding the net/iodine and sysutils/daa2iso ports.Reported by: jbeichPR: 224867, 224868MFC r328090:Pull in r322623 from upstream llvm trunk (by Andrew V. Tischenko):Allow usage of X86-prefixes as separate instrs.Differential Revision: https://reviews.llvm.org/D42102This should fix parse errors when x86 prefixes (such as 'lock' and'rep') are followed by various non-mnemonic tokens, e.g. comments, .bytedirectives and labels.PR: 224669, 225054MFC r328091:Revert r327340, as the workaround for rep prefixes followed by .bytedirectives is no longer needed after r328090.MFC r328141 (by emaste):lld: Fix for ld.lld does not accept "AT" syntax for declaring LMA regionAT> lma_region expression allows to specify the memory regionfor section load address.Should fix [upstream LLVM] PR35684.LLVM review: https://reviews.llvm.org/D41397Obtained from: LLVM r322359 by George RimarMFC r328143 (by emaste):lld: Handle parsing AT(ADDR(.foo-bar)).The problem we had with it is that anything inside an AT is anexpression, so we failed to parse the section name because of the - init.Requested by: roygerObtained from: LLVM r322801 by Rafael EspindolaMFC r328144 (by emaste):lld: Fix incorrect physical address on self-referencing AT command.When a section placement (AT) command references the section itself,the physical address of the section in the ELF header was calculatedincorrectly due to alignment happening right after the locationpointer's value was captured.The problem was diagnosed and the first version of the patch writtenby Erick Reyes.Obtained from: LLVM r322421 by Rafael EspindolaMFC r328145:Pull in r322016 from upstream llvm trunk (by Sanjay Patel):[ValueTracking] remove overzealous assertThe test is derived from a failing fuzz test:https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5008Credit to @rksimon for pointing out the problem.This should fix "Bad flavor while matching min/max" errors when buildingthe graphics/libsixel and science/kst2 ports.Reported by: jbeichPR: 225268, 225269MFC r328146:Pull in r322106 from upstream llvm trunk (by Alexey Bataev):[COST]Fix PR35865: Fix cost model evaluation for shuffle on X86.Summary:If the vector type is transformed to non-vector single type, thecompile may crash trying to get vector information about non-vectortype.Reviewers: RKSimon, spatel, mkuper, hfinkelSubscribers: llvm-commitsDifferential Revision: https://reviews.llvm.org/D41862This should fix "Not a vector MVT!" errors when building thegames/dhewm3 port.Reported by: jbeichPR: 225271MFC r328286 (by emaste):lld: Don't mark a shared library as needed because of a lazy symbol.Obtained from: LLVM r323221 by Rafael Esp?ndolaMFC r328381:Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to6.0.0 (branches/release_60 r323338).PR: 224669MFC r328513:Pull in r322245 from upstream clang trunk (by Craig Topper):[X86] Make -mavx512f imply -mfma and -mf16c in the frontend like itdoes in the backend.Similarly, make -mno-fma and -mno-f16c imply -mno-avx512f.Withou this "-mno-sse -mavx512f" ends up with avx512f being enabledin the frontend but disabled in the backend.Reported by: pawelPR: 225488MFC r328542 (by emaste):lld: Use lookup instead of find. NFC, just simpler.Obtained from: LLVM r323395 by Rafael EspindolaMFC r328543 (by emaste):lld: Only lookup LMARegion once. NFC.This is similar to how we handle MemRegion.Obtained from: LLVM r323396 by Rafael EspindolaMFC r328544 (by emaste):lld: Remove MemRegionOffset. NFC.We can just use a member variable in MemoryRegion.Obtained from: LLVM r323399 by Rafael EspindolaMFC r328545 (by emaste):lld: Simplify. NFC.Obtained from: LLVM r323440 by Rafael EspindolaMFC r328546 (by emaste):lld: Improve LMARegion handling.This fixes the crash reported at [LLVM] PR36083.The issue is that we were trying to put all the sections in the samePT_LOAD and crashing trying to write past the end of the file.This also adds accounting for used space in LMARegion, without it all3 PT_LOADs would have the same physical address.Obtained from: LLVM r323449 by Rafael EspindolaMFC r328547 (by emaste):lld: Move LMAOffset from the OutputSection to the PhdrEntry. NFC.If two sections are in the same PT_LOAD, their relatives offsets,virtual address and physical addresses are all the same.[Rafael] initially wanted to have a single global LMAOffset, on theassumption that every ELF file was in practiced loaded contiguously inboth physical and virtual memory.Unfortunately that is not the case. The linux kernel has:LOAD 0x200000 0xffffffff81000000 0x0000000001000000 0xced000 0xced000 R E 0x200000LOAD 0x1000000 0xffffffff81e00000 0x0000000001e00000 0x15f000 0x15f000 RW 0x200000LOAD 0x1200000 0x0000000000000000 0x0000000001f5f000 0x01b198 0x01b198 RW 0x200000LOAD 0x137b000 0xffffffff81f7b000 0x0000000001f7b000 0x116000 0x1ec000 RWE 0x200000The delta for all but the third PT_LOAD is the same:0xffffffff80000000. [Rafael] thinks the 3rd one is a hack for implementingper cpu data, but we can't break that.Obtained from: LLVM r323456 by Rafael EspindolaMFC r328548 (by emaste):lld: Put the header in the first PT_LOAD even if that PT_LOAD has a LMAExprThe root problem is that we were creating a PT_LOAD just for the header.That was technically valid, but inconvenient: we should not be makingthe ELF discontinuous.The solution is to allow a section with LMAExpr to be added to a PT_LOADif that PT_LOAD doesn't already have a LMAExpr.LLVM PR: 36017Obtained from: LLVM r323625 by Rafael EspindolaMFC r328594 (by emaste):Pull in r322108 from upstream llvm trunk (by Rafael Esp?ndola):Make one of the emitFill methods non virtual. NFC.This is just preparatory work to fix [LLVM] PR35858.MFC r328595 (by emaste):Pull in r322123 from upstream llvm trunk (by Rafael Esp?ndola):Don't create MCFillFragment directly.Instead use higher level APIs that take care of most bookkeeping.MFC r328596 (by emaste):Pull in r322131 from upstream llvm trunk (by Rafael Esp?ndola):Use a MCExpr for the size of MCFillFragment.This allows the size to be found during ralaxation. This fixes[LLVM] pr35858.Requested by: roygerMFC r328753:Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to6.0.0 (branches/release_60 r323948).PR: 224669MFC r328817:Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to6.0.0 (branches/release_60 r324090).This introduces retpoline support, with the -mretpoline flag. Theupstream initial commit message (r323155 by Chandler Carruth) containsquite a bit of explanation. Quoting:Introduce the "retpoline" x86 mitigation technique for variant #2 ofthe speculative execution vulnerabilities disclosed today,specifically identified by CVE-2017-5715, "Branch Target Injection",and is one of the two halves to Spectre.Summary:First, we need to explain the core of the vulnerability. Note thatthis is a very incomplete description, please see the Project Zeroblog post for details:https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.htmlThe basis for branch target injection is to direct speculativeexecution of the processor to some "gadget" of executable code bypoisoning the prediction of indirect branches with the address ofthat gadget. The gadget in turn contains an operation that provides aside channel for reading data. Most commonly, this will look like aload of secret data followed by a branch on the loaded value and thena load of some predictable cache line. The attacker then uses timingof the processors cache to determine which direction the branch took*in the speculative execution*, and in turn what one bit of theloaded value was. Due to the nature of these timing side channels andthe branch predictor on Intel processors, this allows an attacker toleak data only accessible to a privileged domain (like the kernel)back into an unprivileged domain.The goal is simple: avoid generating code which contains an indirectbranch that could have its prediction poisoned by an attacker. Inmany cases, the compiler can simply use directed conditional branchesand a small search tree. LLVM already has support for loweringswitches in this way and the first step of this patch is to disablejump-table lowering of switches and introduce a pass to rewriteexplicit indirectbr sequences into a switch over integers.However, there is no fully general alternative to indirect calls. Weintroduce a new construct we call a "retpoline" to implement indirectcalls in a non-speculatable way. It can be thought of loosely as atrampoline for indirect calls which uses the RET instruction on x86.Further, we arrange for a specific call->ret sequence which ensuresthe processor predicts the return to go to a controlled, knownlocation. The retpoline then "smashes" the return address pushed ontothe stack by the call with the desired target of the originalindirect call. The result is a predicted return to the nextinstruction after a call (which can be used to trap speculativeexecution within an infinite loop) and an actual indirect branch toan arbitrary address.On 64-bit x86 ABIs, this is especially easily done in the compiler byusing a guaranteed scratch register to pass the target into thisdevice. For 32-bit ABIs there isn't a guaranteed scratch registerand so several different retpoline variants are introduced to use ascratch register if one is available in the calling convention and tootherwise use direct stack push/pop sequences to pass the targetaddress.This "retpoline" mitigation is fully described in the following blogpost: https://support.google.com/faqs/answer/7625886We also support a target feature that disables emission of theretpoline thunk by the compiler to allow for custom thunks if userswant them. These are particularly useful in environments likekernels that routinely do hot-patching on boot and want to hot-patchtheir thunk to different code sequences. They can write this customthunk and use `-mretpoline-external-thunk` *in addition* to`-mretpoline`. In this case, on x86-64 thu thunk names must be:```__llvm_external_retpoline_r11```or on 32-bit:```__llvm_external_retpoline_eax__llvm_external_retpoline_ecx__llvm_external_retpoline_edx__llvm_external_retpoline_push```And the target of the retpoline is passed in the named register, or inthe case of the `push` suffix on the top of the stack via a `pushl`instruction.There is one other important source of indirect branches in x86 ELFbinaries: the PLT. These patches also include support for LLD togenerate PLT entries that perform a retpoline-style indirection.The only other indirect branches remaining that we are aware of arefrom precompiled runtimes (such as crt0.o and similar). The ones wehave found are not really attackable, and so we have not focused onthem here, but eventually these runtimes should also be replicated forretpoline-ed configurations for completeness.For kernels or other freestanding or fully static executables, thecompiler switch `-mretpoline` is sufficient to fully mitigate thisparticular attack. For dynamic executables, you must compile *all*libraries with `-mretpoline` and additionally link the dynamicexecutable and all shared libraries with LLD and pass `-zretpolineplt` (or use similar functionality from some other linker).We strongly recommend also using `-z now` as non-lazy binding allowsthe retpoline-mitigated PLT to be substantially smaller.When manually apply similar transformations to `-mretpoline` to theLinux kernel we observed very small performance hits to applicationsrunning typic al workloads, and relatively minor hits (approximately2%) even for extremely syscall-heavy applications. This is largelydue to the small number of indirect branches that occur inperformance sensitive paths of the kernel.When using these patches on statically linked applications,especially C++ applications, you should expect to see a much moredramatic performance hit. For microbenchmarks that are switch,indirect-, or virtual-call heavy we have seen overheads ranging from10% to 50%.However, real-world workloads exhibit substantially lower performanceimpact. Notably, techniques such as PGO and ThinLTO dramaticallyreduce the impact of hot indirect calls (by speculatively promotingthem to direct calls) and allow optimized search trees to be used tolower switches. If you need to deploy these techniques in C++applications, we *strongly* recommend that you ensure all hot calltargets are statically linked (avoiding PLT indirection) and use bothPGO and ThinLTO. Well tuned servers using all of these techniques saw5% - 10% overhead from the use of retpoline.We will add detailed documentation covering these components insubsequent patches, but wanted to make the core functionalityavailable as soon as possible. Happy for more code review, but we'dreally like to get these patches landed and backported ASAP forobvious reasons. We're planning to backport this to both 6.0 and 5.0release streams and get a 5.0 release with just this cherry pickedASAP for distros and vendors.This patch is the work of a number of people over the past month:Eric, Reid, Rui, and myself. I'm mailing it out as a single commitdue to the time sensitive nature of landing this and the need tobackport it. Huge thanks to everyone who helped out here, andeveryone at Intel who helped out in discussions about how to craftthis. Also, credit goes to Paul Turner (at Google, but not an LLVMcontributor) for much of the underlying retpoline design.Reviewers: echristo, rnk, ruiu, craig.topper, DavidKreitzerSubscribers: sanjoy, emaste, mcrosier, mgorny, mehdi_amini, hiraditya, llvm-commitsDifferential Revision: https://reviews.llvm.org/D41723PR: 224669MFC r329033:Pull in r324594 from upstream clang trunk (by Alexander Ivchenko):Fix for #31362 - ms_abi is implemented incorrectly for values >=16bytes.Summary:This patch is a fix for following issue:https://bugs.llvm.org/show_bug.cgi?id=31362 The problem was caused byfront end lowering C calling conventions without taking into accountcalling conventions enforced by attribute. In this case win64cc wasno correctly lowered on targets other than Windows.Reviewed By: rnk (Reid Kleckner)Differential Revision: https://reviews.llvm.org/D43016Author: belickim <mateusz.belicki@intel.com>This fixes clang 6.0.0 assertions when building the emulators/wine andemulators/wine-devel ports, and should also make it use the correctWindows calling conventions. Bump __FreeBSD_version to make the fixeasy to detect.PR: 224863MFC r329223:Pull in r323998 from upstream clang trunk (by Richard Smith):PR36157: When injecting an implicit function declaration in C89, findthe right DeclContext rather than injecting it wherever we happen tobe.This avoids creating functions whose DeclContext is a struct orsimilar.This fixes assertion failures when parsing certain not-completely-validstruct declarations.Reported by: aePR: 225862MFC r329410:Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to6.0.0 (branches/release_60 r325330).PR: 224669MFC r329983:Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to6.0.0 (branches/release_60 r325932). This corresponds to 6.0.0 rc3.PR: 224669MFC r330384:Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to6.0.0 release (upstream r326565).Release notes for llvm, clang and lld will be available here soon:<http://releases.llvm.org/6.0.0/docs/ReleaseNotes.html><http://releases.llvm.org/6.0.0/tools/clang/docs/ReleaseNotes.html><http://releases.llvm.org/6.0.0/tools/lld/docs/ReleaseNotes.html>Relnotes: yesPR: 224669MFC r330686:Pull in r326882 from upstream llvm trunk (by Sjoerd Meijer):[ARM] Fix for PR36577Don't PerformSHLSimplify if the given node is used by a node thatalso uses a constant because we may get stuck in an infinite combineloop.bugzilla: https://bugs.llvm.org/show_bug.cgi?id=36577Patch by Sam Parker.Differential Revision: https://reviews.llvm.org/D44097This fixes a hang when compiling one particular file in java/openjdk8for armv6 and armv7.Reported by: swillsPR: 226388MFC r331065:Pull in r327638 from upstream llvm trunk (by Matthew Simpson):[ConstantFolding, InstSimplify] Handle more vector GEPsThis patch addresses some additional cases where the compiler crashesupon encountering vector GEPs. This should fix PR36116.Differential Revision: https://reviews.llvm.org/D44219Reference: https://bugs.llvm.org/show_bug.cgi?id=36116This fixes an assertion when building the emulators/snes9x port.Reported by: jbeichPR: 225471MFC r331066:Pull in r321999 from upstream clang trunk (by Ivan A. Kosarev):[CodeGen] Fix TBAA info for accesses to members of base classesResolves:Bug 35724 - regression (r315984): fatal error: error in backend:Broken function found (Did not see access type in access path!)https://bugs.llvm.org/show_bug.cgi?id=35724Differential Revision: https://reviews.llvm.org/D41547This fixes "Did not see access type in access path" fatal errors whenbuilding the devel/gdb port (version 8.1).Reported by: jbeichPR: 226658MFC r331366:Pull in r327101 from upstream llvm trunk (by Rafael Espindola):Don't treat .symver as a regular alias definition.This patch starts simplifying the handling of .symver.For now it just moves the responsibility for creating an alias down tothe streamer. With that the asm streamer can pass a .symver unchanged,which is nice since gas cannot parse "foo@bar = zed".In a followup I hope to move the handling down to the writer so thatwe don't need special hacks for avoiding breaking names with @@@ onwindows.Pull in r327160 from upstream llvm trunk (by Rafael Espindola):Delay creating an alias for @@@.With this we only create an alias for @@@ once we know if it shoulduse @ or @@. This avoids last minutes renames and hacks to handle MSnames.This only handles the ELF writer. LTO still has issues with @@@aliases.Pull in r327928 from upstream llvm trunk (by Vitaly Buka):Object: Move attribute calculation into RecordStreamer. NFCSummary: Preparation for D44274Reviewers: pcc, espindolaSubscribers: hiradityaDifferential Revision: https://reviews.llvm.org/D44276Pull in r327930 from upstream llvm trunk (by Vitaly Buka):Object: Fix handling of @@@ in .symver directiveSummary:name@@@nodename is going to be replaced with name@@nodename if symbols isdefined in the assembled file, or name@nodename if undefined.https://sourceware.org/binutils/docs/as/Symver.htmlFixes PR36623Reviewers: pcc, espindolaSubscribers: mehdi_amini, hiradityaDifferential Revision: https://reviews.llvm.org/D44274Together, these changes fix handling of @@@ in .symver directives whendoing Link Time Optimization.Reported by: Shawn Webb <shawn.webb@hardenedbsd.org>MFC r331731:Pull in r328738 from upstream lld trunk (by Rafael Espindola):Strip @VER suffices from the LTO output.This fixes pr36623.The problem is that we have to parse versions out of names before LTOso that LTO can use that information.When we get the LTO produced .o files, we replace the previous symbolswith the LTO produced ones, but they still have @ in their names.We could just trim the name directly, but calling parseSymbolVersionto do it is simpler.This is a follow-up to r331366, since we discovered that lld couldappend version strings to symbols twice, when using Link TimeOptimization.
2018-03-31 10:23:33.734522331838dimstable/11/ObsoleteFiles.inc
stable/11/UPDATING
stable/11/contrib/compiler-rt/include/sanitizer/allocator_interface.h
4605 more...
Merge clang, llvm, lld, lldb, compiler-rt and libc++ 6.0.0 release, andseveral follow-up fixes.MFC r327952:Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to6.0.0 (branches/release_60 r321788). Upstream has branched for the6.0.0 release, which should be in about 6 weeks. Please report bugs andregressions, so we can get them into the release.Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11support to build; see UPDATING for more information.MFC r328010:Pull in r322473 from upstream llvm trunk (by Andrei Elovikov):[LV] Don't call recordVectorLoopValueForInductionCast fornewly-created IV from a trunc.Summary:This method is supposed to be called for IVs that have casts in theiruse-def chains that are completely ignored after vectorization underPSE. However, for truncates of such IVs the same InductionDescriptoris used during creation/widening of both original IV based on PHINodeand new IV based on TruncInst.This leads to unintended second call torecordVectorLoopValueForInductionCast with a VectorLoopVal set to thenewly created IV for a trunc and causes an assert due to attempt tostore new information for already existing entry in the map. This iswrong and should not be done.Fixes PR35773.Reviewers: dorit, Ayal, mssimpsoReviewed By: doritSubscribers: RKSimon, dim, dcaballe, hsaito, llvm-commits, hiradityaDifferential Revision: https://reviews.llvm.org/D41913This should fix "Vector value already set for part" assertions whenbuilding the net/iodine and sysutils/daa2iso ports.Reported by: jbeichPR: 224867, 224868MFC r328090:Pull in r322623 from upstream llvm trunk (by Andrew V. Tischenko):Allow usage of X86-prefixes as separate instrs.Differential Revision: https://reviews.llvm.org/D42102This should fix parse errors when x86 prefixes (such as 'lock' and'rep') are followed by various non-mnemonic tokens, e.g. comments, .bytedirectives and labels.PR: 224669, 225054MFC r328091:Revert r327340, as the workaround for rep prefixes followed by .bytedirectives is no longer needed after r328090.MFC r328141 (by emaste):lld: Fix for ld.lld does not accept "AT" syntax for declaring LMA regionAT> lma_region expression allows to specify the memory regionfor section load address.Should fix [upstream LLVM] PR35684.LLVM review: https://reviews.llvm.org/D41397Obtained from: LLVM r322359 by George RimarMFC r328143 (by emaste):lld: Handle parsing AT(ADDR(.foo-bar)).The problem we had with it is that anything inside an AT is anexpression, so we failed to parse the section name because of the - init.Requested by: roygerObtained from: LLVM r322801 by Rafael EspindolaMFC r328144 (by emaste):lld: Fix incorrect physical address on self-referencing AT command.When a section placement (AT) command references the section itself,the physical address of the section in the ELF header was calculatedincorrectly due to alignment happening right after the locationpointer's value was captured.The problem was diagnosed and the first version of the patch writtenby Erick Reyes.Obtained from: LLVM r322421 by Rafael EspindolaMFC r328145:Pull in r322016 from upstream llvm trunk (by Sanjay Patel):[ValueTracking] remove overzealous assertThe test is derived from a failing fuzz test:https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5008Credit to @rksimon for pointing out the problem.This should fix "Bad flavor while matching min/max" errors when buildingthe graphics/libsixel and science/kst2 ports.Reported by: jbeichPR: 225268, 225269MFC r328146:Pull in r322106 from upstream llvm trunk (by Alexey Bataev):[COST]Fix PR35865: Fix cost model evaluation for shuffle on X86.Summary:If the vector type is transformed to non-vector single type, thecompile may crash trying to get vector information about non-vectortype.Reviewers: RKSimon, spatel, mkuper, hfinkelSubscribers: llvm-commitsDifferential Revision: https://reviews.llvm.org/D41862This should fix "Not a vector MVT!" errors when building thegames/dhewm3 port.Reported by: jbeichPR: 225271MFC r328286 (by emaste):lld: Don't mark a shared library as needed because of a lazy symbol.Obtained from: LLVM r323221 by Rafael Esp?ndolaMFC r328381:Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to6.0.0 (branches/release_60 r323338).PR: 224669MFC r328513:Pull in r322245 from upstream clang trunk (by Craig Topper):[X86] Make -mavx512f imply -mfma and -mf16c in the frontend like itdoes in the backend.Similarly, make -mno-fma and -mno-f16c imply -mno-avx512f.Withou this "-mno-sse -mavx512f" ends up with avx512f being enabledin the frontend but disabled in the backend.Reported by: pawelPR: 225488MFC r328542 (by emaste):lld: Use lookup instead of find. NFC, just simpler.Obtained from: LLVM r323395 by Rafael EspindolaMFC r328543 (by emaste):lld: Only lookup LMARegion once. NFC.This is similar to how we handle MemRegion.Obtained from: LLVM r323396 by Rafael EspindolaMFC r328544 (by emaste):lld: Remove MemRegionOffset. NFC.We can just use a member variable in MemoryRegion.Obtained from: LLVM r323399 by Rafael EspindolaMFC r328545 (by emaste):lld: Simplify. NFC.Obtained from: LLVM r323440 by Rafael EspindolaMFC r328546 (by emaste):lld: Improve LMARegion handling.This fixes the crash reported at [LLVM] PR36083.The issue is that we were trying to put all the sections in the samePT_LOAD and crashing trying to write past the end of the file.This also adds accounting for used space in LMARegion, without it all3 PT_LOADs would have the same physical address.Obtained from: LLVM r323449 by Rafael EspindolaMFC r328547 (by emaste):lld: Move LMAOffset from the OutputSection to the PhdrEntry. NFC.If two sections are in the same PT_LOAD, their relatives offsets,virtual address and physical addresses are all the same.[Rafael] initially wanted to have a single global LMAOffset, on theassumption that every ELF file was in practiced loaded contiguously inboth physical and virtual memory.Unfortunately that is not the case. The linux kernel has:LOAD 0x200000 0xffffffff81000000 0x0000000001000000 0xced000 0xced000 R E 0x200000LOAD 0x1000000 0xffffffff81e00000 0x0000000001e00000 0x15f000 0x15f000 RW 0x200000LOAD 0x1200000 0x0000000000000000 0x0000000001f5f000 0x01b198 0x01b198 RW 0x200000LOAD 0x137b000 0xffffffff81f7b000 0x0000000001f7b000 0x116000 0x1ec000 RWE 0x200000The delta for all but the third PT_LOAD is the same:0xffffffff80000000. [Rafael] thinks the 3rd one is a hack for implementingper cpu data, but we can't break that.Obtained from: LLVM r323456 by Rafael EspindolaMFC r328548 (by emaste):lld: Put the header in the first PT_LOAD even if that PT_LOAD has a LMAExprThe root problem is that we were creating a PT_LOAD just for the header.That was technically valid, but inconvenient: we should not be makingthe ELF discontinuous.The solution is to allow a section with LMAExpr to be added to a PT_LOADif that PT_LOAD doesn't already have a LMAExpr.LLVM PR: 36017Obtained from: LLVM r323625 by Rafael EspindolaMFC r328594 (by emaste):Pull in r322108 from upstream llvm trunk (by Rafael Esp?ndola):Make one of the emitFill methods non virtual. NFC.This is just preparatory work to fix [LLVM] PR35858.MFC r328595 (by emaste):Pull in r322123 from upstream llvm trunk (by Rafael Esp?ndola):Don't create MCFillFragment directly.Instead use higher level APIs that take care of most bookkeeping.MFC r328596 (by emaste):Pull in r322131 from upstream llvm trunk (by Rafael Esp?ndola):Use a MCExpr for the size of MCFillFragment.This allows the size to be found during ralaxation. This fixes[LLVM] pr35858.Requested by: roygerMFC r328753:Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to6.0.0 (branches/release_60 r323948).PR: 224669MFC r328817:Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to6.0.0 (branches/release_60 r324090).This introduces retpoline support, with the -mretpoline flag. Theupstream initial commit message (r323155 by Chandler Carruth) containsquite a bit of explanation. Quoting:Introduce the "retpoline" x86 mitigation technique for variant #2 ofthe speculative execution vulnerabilities disclosed today,specifically identified by CVE-2017-5715, "Branch Target Injection",and is one of the two halves to Spectre.Summary:First, we need to explain the core of the vulnerability. Note thatthis is a very incomplete description, please see the Project Zeroblog post for details:https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.htmlThe basis for branch target injection is to direct speculativeexecution of the processor to some "gadget" of executable code bypoisoning the prediction of indirect branches with the address ofthat gadget. The gadget in turn contains an operation that provides aside channel for reading data. Most commonly, this will look like aload of secret data followed by a branch on the loaded value and thena load of some predictable cache line. The attacker then uses timingof the processors cache to determine which direction the branch took*in the speculative execution*, and in turn what one bit of theloaded value was. Due to the nature of these timing side channels andthe branch predictor on Intel processors, this allows an attacker toleak data only accessible to a privileged domain (like the kernel)back into an unprivileged domain.The goal is simple: avoid generating code which contains an indirectbranch that could have its prediction poisoned by an attacker. Inmany cases, the compiler can simply use directed conditional branchesand a small search tree. LLVM already has support for loweringswitches in this way and the first step of this patch is to disablejump-table lowering of switches and introduce a pass to rewriteexplicit indirectbr sequences into a switch over integers.However, there is no fully general alternative to indirect calls. Weintroduce a new construct we call a "retpoline" to implement indirectcalls in a non-speculatable way. It can be thought of loosely as atrampoline for indirect calls which uses the RET instruction on x86.Further, we arrange for a specific call->ret sequence which ensuresthe processor predicts the return to go to a controlled, knownlocation. The retpoline then "smashes" the return address pushed ontothe stack by the call with the desired target of the originalindirect call. The result is a predicted return to the nextinstruction after a call (which can be used to trap speculativeexecution within an infinite loop) and an actual indirect branch toan arbitrary address.On 64-bit x86 ABIs, this is especially easily done in the compiler byusing a guaranteed scratch register to pass the target into thisdevice. For 32-bit ABIs there isn't a guaranteed scratch registerand so several different retpoline variants are introduced to use ascratch register if one is available in the calling convention and tootherwise use direct stack push/pop sequences to pass the targetaddress.This "retpoline" mitigation is fully described in the following blogpost: https://support.google.com/faqs/answer/7625886We also support a target feature that disables emission of theretpoline thunk by the compiler to allow for custom thunks if userswant them. These are particularly useful in environments likekernels that routinely do hot-patching on boot and want to hot-patchtheir thunk to different code sequences. They can write this customthunk and use `-mretpoline-external-thunk` *in addition* to`-mretpoline`. In this case, on x86-64 thu thunk names must be:```__llvm_external_retpoline_r11```or on 32-bit:```__llvm_external_retpoline_eax__llvm_external_retpoline_ecx__llvm_external_retpoline_edx__llvm_external_retpoline_push```And the target of the retpoline is passed in the named register, or inthe case of the `push` suffix on the top of the stack via a `pushl`instruction.There is one other important source of indirect branches in x86 ELFbinaries: the PLT. These patches also include support for LLD togenerate PLT entries that perform a retpoline-style indirection.The only other indirect branches remaining that we are aware of arefrom precompiled runtimes (such as crt0.o and similar). The ones wehave found are not really attackable, and so we have not focused onthem here, but eventually these runtimes should also be replicated forretpoline-ed configurations for completeness.For kernels or other freestanding or fully static executables, thecompiler switch `-mretpoline` is sufficient to fully mitigate thisparticular attack. For dynamic executables, you must compile *all*libraries with `-mretpoline` and additionally link the dynamicexecutable and all shared libraries with LLD and pass `-zretpolineplt` (or use similar functionality from some other linker).We strongly recommend also using `-z now` as non-lazy binding allowsthe retpoline-mitigated PLT to be substantially smaller.When manually apply similar transformations to `-mretpoline` to theLinux kernel we observed very small performance hits to applicationsrunning typic al workloads, and relatively minor hits (approximately2%) even for extremely syscall-heavy applications. This is largelydue to the small number of indirect branches that occur inperformance sensitive paths of the kernel.When using these patches on statically linked applications,especially C++ applications, you should expect to see a much moredramatic performance hit. For microbenchmarks that are switch,indirect-, or virtual-call heavy we have seen overheads ranging from10% to 50%.However, real-world workloads exhibit substantially lower performanceimpact. Notably, techniques such as PGO and ThinLTO dramaticallyreduce the impact of hot indirect calls (by speculatively promotingthem to direct calls) and allow optimized search trees to be used tolower switches. If you need to deploy these techniques in C++applications, we *strongly* recommend that you ensure all hot calltargets are statically linked (avoiding PLT indirection) and use bothPGO and ThinLTO. Well tuned servers using all of these techniques saw5% - 10% overhead from the use of retpoline.We will add detailed documentation covering these components insubsequent patches, but wanted to make the core functionalityavailable as soon as possible. Happy for more code review, but we'dreally like to get these patches landed and backported ASAP forobvious reasons. We're planning to backport this to both 6.0 and 5.0release streams and get a 5.0 release with just this cherry pickedASAP for distros and vendors.This patch is the work of a number of people over the past month:Eric, Reid, Rui, and myself. I'm mailing it out as a single commitdue to the time sensitive nature of landing this and the need tobackport it. Huge thanks to everyone who helped out here, andeveryone at Intel who helped out in discussions about how to craftthis. Also, credit goes to Paul Turner (at Google, but not an LLVMcontributor) for much of the underlying retpoline design.Reviewers: echristo, rnk, ruiu, craig.topper, DavidKreitzerSubscribers: sanjoy, emaste, mcrosier, mgorny, mehdi_amini, hiraditya, llvm-commitsDifferential Revision: https://reviews.llvm.org/D41723PR: 224669MFC r329033:Pull in r324594 from upstream clang trunk (by Alexander Ivchenko):Fix for #31362 - ms_abi is implemented incorrectly for values >=16bytes.Summary:This patch is a fix for following issue:https://bugs.llvm.org/show_bug.cgi?id=31362 The problem was caused byfront end lowering C calling conventions without taking into accountcalling conventions enforced by attribute. In this case win64cc wasno correctly lowered on targets other than Windows.Reviewed By: rnk (Reid Kleckner)Differential Revision: https://reviews.llvm.org/D43016Author: belickim <mateusz.belicki@intel.com>This fixes clang 6.0.0 assertions when building the emulators/wine andemulators/wine-devel ports, and should also make it use the correctWindows calling conventions. Bump __FreeBSD_version to make the fixeasy to detect.PR: 224863MFC r329223:Pull in r323998 from upstream clang trunk (by Richard Smith):PR36157: When injecting an implicit function declaration in C89, findthe right DeclContext rather than injecting it wherever we happen tobe.This avoids creating functions whose DeclContext is a struct orsimilar.This fixes assertion failures when parsing certain not-completely-validstruct declarations.Reported by: aePR: 225862MFC r329410:Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to6.0.0 (branches/release_60 r325330).PR: 224669MFC r329983:Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to6.0.0 (branches/release_60 r325932). This corresponds to 6.0.0 rc3.PR: 224669MFC r330384:Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to6.0.0 release (upstream r326565).Release notes for llvm, clang and lld will be available here soon:<http://releases.llvm.org/6.0.0/docs/ReleaseNotes.html><http://releases.llvm.org/6.0.0/tools/clang/docs/ReleaseNotes.html><http://releases.llvm.org/6.0.0/tools/lld/docs/ReleaseNotes.html>Relnotes: yesPR: 224669MFC r330686:Pull in r326882 from upstream llvm trunk (by Sjoerd Meijer):[ARM] Fix for PR36577Don't PerformSHLSimplify if the given node is used by a node thatalso uses a constant because we may get stuck in an infinite combineloop.bugzilla: https://bugs.llvm.org/show_bug.cgi?id=36577Patch by Sam Parker.Differential Revision: https://reviews.llvm.org/D44097This fixes a hang when compiling one particular file in java/openjdk8for armv6 and armv7.Reported by: swillsPR: 226388MFC r331065:Pull in r327638 from upstream llvm trunk (by Matthew Simpson):[ConstantFolding, InstSimplify] Handle more vector GEPsThis patch addresses some additional cases where the compiler crashesupon encountering vector GEPs. This should fix PR36116.Differential Revision: https://reviews.llvm.org/D44219Reference: https://bugs.llvm.org/show_bug.cgi?id=36116This fixes an assertion when building the emulators/snes9x port.Reported by: jbeichPR: 225471MFC r331066:Pull in r321999 from upstream clang trunk (by Ivan A. Kosarev):[CodeGen] Fix TBAA info for accesses to members of base classesResolves:Bug 35724 - regression (r315984): fatal error: error in backend:Broken function found (Did not see access type in access path!)https://bugs.llvm.org/show_bug.cgi?id=35724Differential Revision: https://reviews.llvm.org/D41547This fixes "Did not see access type in access path" fatal errors whenbuilding the devel/gdb port (version 8.1).Reported by: jbeichPR: 226658MFC r331366:Pull in r327101 from upstream llvm trunk (by Rafael Espindola):Don't treat .symver as a regular alias definition.This patch starts simplifying the handling of .symver.For now it just moves the responsibility for creating an alias down tothe streamer. With that the asm streamer can pass a .symver unchanged,which is nice since gas cannot parse "foo@bar = zed".In a followup I hope to move the handling down to the writer so thatwe don't need special hacks for avoiding breaking names with @@@ onwindows.Pull in r327160 from upstream llvm trunk (by Rafael Espindola):Delay creating an alias for @@@.With this we only create an alias for @@@ once we know if it shoulduse @ or @@. This avoids last minutes renames and hacks to handle MSnames.This only handles the ELF writer. LTO still has issues with @@@aliases.Pull in r327928 from upstream llvm trunk (by Vitaly Buka):Object: Move attribute calculation into RecordStreamer. NFCSummary: Preparation for D44274Reviewers: pcc, espindolaSubscribers: hiradityaDifferential Revision: https://reviews.llvm.org/D44276Pull in r327930 from upstream llvm trunk (by Vitaly Buka):Object: Fix handling of @@@ in .symver directiveSummary:name@@@nodename is going to be replaced with name@@nodename if symbols isdefined in the assembled file, or name@nodename if undefined.https://sourceware.org/binutils/docs/as/Symver.htmlFixes PR36623Reviewers: pcc, espindolaSubscribers: mehdi_amini, hiradityaDifferential Revision: https://reviews.llvm.org/D44274Together, these changes fix handling of @@@ in .symver directives whendoing Link Time Optimization.Reported by: Shawn Webb <shawn.webb@hardenedbsd.org>MFC r331731:Pull in r328738 from upstream lld trunk (by Rafael Espindola):Strip @VER suffices from the LTO output.This fixes pr36623.The problem is that we have to parse versions out of names before LTOso that LTO can use that information.When we get the LTO produced .o files, we replace the previous symbolswith the LTO produced ones, but they still have @ in their names.We could just trim the name directly, but calling parseSymbolVersionto do it is simpler.This is a follow-up to r331366, since we discovered that lld couldappend version strings to symbols twice, when using Link TimeOptimization.
2018-03-31 10:23:31.77519331796hselasky

MFC r330655:Remove duplicate prototypes (update mergeinfo only).Sponsored by: Mellanox Technologies
2018-03-31 10:23:31.77519331796hselasky

MFC r330655:Remove duplicate prototypes (update mergeinfo only).Sponsored by: Mellanox Technologies
2018-03-31 10:23:14.773865331685kevans

Record-only MFC of r330252, r330253r330253 reverted r330252, which was committed with nothing but the message:"MFC After: 1 week"Go ahead and record the merge of both of them. r330254 was the follow-upcommit with the same contents as r330252 but with an appropriate message. Itwill be MFC'd along with the introduction of the corresponding options asappropriate.
2018-03-31 10:23:14.773865331685kevans

Record-only MFC of r330252, r330253r330253 reverted r330252, which was committed with nothing but the message:"MFC After: 1 week"Go ahead and record the merge of both of them. r330254 was the follow-upcommit with the same contents as r330252 but with an appropriate message. Itwill be MFC'd along with the introduction of the corresponding options asappropriate.
2018-03-25 10:04:11.630883331494ian

Record-only merge of r324416. The actual code was merged in 327633, butI forgot to add the merge info then (it wasn't so much a merge asrecreating on the branch the same conceptual change as was done on head).