and though bugs are the bane of my existence, rest assured the wretched thing will get the best of care here

  1. 28 Mar, 2018 1 commit
  2. 16 Mar, 2018 3 commits
    • Simon Dardis's avatar
      Backporting r325647 and r325713: · 4e1dadff
      Simon Dardis authored
      ```---------------------------------------------------------------------
      r325713 | sdardis | 2018-02-21 20:01:43 +0000 (Wed, 21 Feb 2018) | 5 lines
      
      [mips][lld] Address post commit review nit.
      
      Address @ruiu's post commit review comment about a value which is intended
      to be a unsigned 32 bit integer as using uint32_t rather than unsigned.
      ```
      
      ---------------------------------------------------------------------
      ------------------------------------------------------------------------
      r325647 | sdardis | 2018-02-20 23:49:17 +0000 (Tue, 20 Feb 2018) | 27 lines
      
      [mips][lld] Spectre variant two mitigation for MIPSR2
      
      This patch provides migitation for CVE-2017-5715, Spectre variant two,
      which affects the P5600 and P6600. It implements the LLD part of
      -z hazardplt. Like the Clang part of this patch, I have opted for that
      specific option name in case alternative migitation methods are required
      in the future.
      
      The mitigation strategy suggested by MIPS for these processors is to use
      hazard barrier instructions. 'jalr.hb' and 'jr.hb' are hazard
      barrier variants of the 'jalr' and 'jr' instructions respectively.
      
      These instructions impede the execution of instruction stream until
      architecturally defined hazards (changes to the instruction stream,
      privileged registers which may affect execution) are cleared. These
      instructions in MIPS' designs are not speculated past.
      
      These instructions are defined by the MIPS32R2 ISA, so this mitigation
      method is not compatible with processors which implement an earlier
      revision of the MIPS ISA.
      
      For LLD, this changes PLT stubs to use 'jalr.hb' and 'jr.hb'.
      
      Reviewers: atanasyan, ruiu
      
      Differential Revision: https://reviews.llvm.org/D43488
      
      ------------------------------------------------------------------------
      
      llvm-svn: 327757
      4e1dadff
    • Simon Dardis's avatar
      Backporting 325651:: · c3a89385
      Simon Dardis authored
      ```---------------------------------------------------------------------
      r325651 | sdardis | 2018-02-21 00:05:05 +0000 (Wed, 21 Feb 2018) | 34 lines
      
      [mips] Spectre variant two mitigation for MIPSR2
      
      This patch provides mitigation for CVE-2017-5715, Spectre variant two,
      which affects the P5600 and P6600. It provides the option
      -mindirect-jump=hazard, which instructs the LLVM backend to replace
      indirect branches with their hazard barrier variants.
      
      This option is accepted when targeting MIPS revision two or later.
      
      The migitation strategy suggested by MIPS for these processors is to
      use two hazard barrier instructions. 'jalr.hb' and 'jr.hb' are hazard
      barrier variants of the 'jalr' and 'jr' instructions respectively.
      
      These instructions impede the execution of instruction stream until
      architecturally defined hazards (changes to the instruction stream,
      privileged registers which may affect execution) are cleared. These
      instructions in MIPS' designs are not speculated past.
      
      These instructions are used with the option -mindirect-jump=hazard
      when branching indirectly and for indirect function calls.
      
      These instructions are defined by the MIPS32R2 ISA, so this mitigation
      method is not compatible with processors which implement an earlier
      revision of the MIPS ISA.
      
      Implementation note: I've opted to provide this as an
      -mindirect-jump={hazard,...} style option in case alternative
      mitigation methods are required for other implementations of the MIPS
      ISA in future, e.g. retpoline style solutions.
      
      Reviewers: atanasyan
      
      Differential Revision: https://reviews.llvm.org/D43487
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 327755
      c3a89385
    • Simon Dardis's avatar
      Backporting r325653: · 64778dce
      Simon Dardis authored
      ```---------------------------------------------------------------------
      r325653 | sdardis | 2018-02-21 00:06:53 +0000 (Wed, 21 Feb 2018) | 31 lines
      
      [mips] Spectre variant two mitigation for MIPSR2
      
      This patch provides mitigation for CVE-2017-5715, Spectre variant two,
      which affects the P5600 and P6600. It implements the LLVM part of
      -mindirect-jump=hazard. It is _not_ enabled by default for the P5600.
      
      The migitation strategy suggested by MIPS for these processors is to use
      hazard barrier instructions. 'jalr.hb' and 'jr.hb' are hazard
      barrier variants of the 'jalr' and 'jr' instructions respectively.
      
      These instructions impede the execution of instruction stream until
      architecturally defined hazards (changes to the instruction stream,
      privileged registers which may affect execution) are cleared. These
      instructions in MIPS' designs are not speculated past.
      
      These instructions are used with the attribute +use-indirect-jump-hazard
      when branching indirectly and for indirect function calls.
      
      These instructions are defined by the MIPS32R2 ISA, so this mitigation
      method is not compatible with processors which implement an earlier
      revision of the MIPS ISA.
      
      Performance benchmarking of this option with -fpic and lld using
      -z hazardplt shows a difference of overall 10%~ time increase
      for the LLVM testsuite. Certain benchmarks such as methcall show a
      substantially larger increase in time due to their nature.
      
      Reviewers: atanasyan, zoran.jovanovic
      
      Differential Revision: https://reviews.llvm.org/D43486
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 327751
      64778dce
  3. 14 Feb, 2018 4 commits
    • Reid Kleckner's avatar
      Merging r325085: · 0d404721
      Reid Kleckner authored
      ```---------------------------------------------------------------------
      r325085 | rnk | 2018-02-13 16:24:29 -0800 (Tue, 13 Feb 2018) | 3 lines
      
      [X86] Remove dead code from retpoline thunk generation
      
      Follow-up to r325049
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 325091
      0d404721
    • Reid Kleckner's avatar
      Merging r325049: · 2caa8716
      Reid Kleckner authored
      ```---------------------------------------------------------------------
      r325049 | rnk | 2018-02-13 12:47:49 -0800 (Tue, 13 Feb 2018) | 17 lines
      
      [X86] Use EDI for retpoline when no scratch regs are left
      
      Summary:
      Instead of solving the hard problem of how to pass the callee to the indirect
      jump thunk without a register, just use a CSR. At a call boundary, there's
      nothing stopping us from using a CSR to hold the callee as long as we save and
      restore it in the prologue.
      
      Also, add tests for this mregparm=3 case. I wrote execution tests for
      __llvm_retpoline_push, but they never got committed as lit tests, either
      because I never rewrote them or because they got lost in merge conflicts.
      
      Reviewers: chandlerc, dwmw2
      
      Subscribers: javed.absar, kristof.beyls, hiraditya, llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D43214
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 325090
      2caa8716
    • Reid Kleckner's avatar
      Merging r324645: · 940d56c1
      Reid Kleckner authored
      ```---------------------------------------------------------------------
      r324645 | dwmw2 | 2018-02-08 12:06:05 -0800 (Thu, 08 Feb 2018) | 5 lines
      
      [X86] Support 'V' register operand modifier
      
      This allows the register name to be printed without the leading '%'.
      This can be used for emitting calls to the retpoline thunks from inline
      asm.
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 325089
      940d56c1
    • Reid Kleckner's avatar
      Merging r324449: · 754e957b
      Reid Kleckner authored
      ```---------------------------------------------------------------------
      r324449 | chandlerc | 2018-02-06 22:16:24 -0800 (Tue, 06 Feb 2018) | 15 lines
      
      [x86/retpoline] Make the external thunk names exactly match the names
      that happened to end up in GCC.
      
      This is really unfortunate, as the names don't have much rhyme or reason
      to them. Originally in the discussions it seemed fine to rely on aliases
      to map different names to whatever external thunk code developers wished
      to use but there are practical problems with that in the kernel it turns
      out. And since we're discovering this practical problems late and since
      GCC has already shipped a release with one set of names, we are forced,
      yet again, to blindly match what is there.
      
      Somewhat rushing this patch out for the Linux kernel folks to test and
      so we can get it patched into our releases.
      
      Differential Revision: https://reviews.llvm.org/D42998
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 325088
      754e957b
  4. 01 Feb, 2018 5 commits
    • Reid Kleckner's avatar
      Merging r323288: · 0e39460d
      Reid Kleckner authored
      ```---------------------------------------------------------------------
      r323288 | ruiu | 2018-01-23 16:26:57 -0800 (Tue, 23 Jan 2018) | 3 lines
      
      Fix retpoline PLT header size for i386.
      
      Differential Revision: https://reviews.llvm.org/D42397
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 324026
      0e39460d
    • Reid Kleckner's avatar
      Merging r323155 in LLD, with modifications to handle int3 fill · ff3a8f17
      Reid Kleckner authored
      Original commit message:
      ------------------------------------------------------------------------
      r323155 | chandlerc | 2018-01-22 14:05:25 -0800 (Mon, 22 Jan 2018) | 133 lines
      
      Introduce the "retpoline" x86 mitigation technique for variant #2 of the 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 that this
      is a very incomplete description, please see the Project Zero blog post
      for details:
      https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
      
      The basis for branch target injection is to direct speculative execution
      of the processor to some "gadget" of executable code by poisoning the
      prediction of indirect branches with the address of that gadget. The
      gadget in turn contains an operation that provides a side channel for
      reading data. Most commonly, this will look like a load of secret data
      followed by a branch on the loaded value and then a load of some
      predictable cache line. The attacker then uses timing of the processors
      cache to determine which direction the branch took *in the speculative
      execution*, and in turn what one bit of the loaded value was. Due to the
      nature of these timing side channels and the branch predictor on Intel
      processors, this allows an attacker to leak 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 indirect
      branch that could have its prediction poisoned by an attacker. In many
      cases, the compiler can simply use directed conditional branches and
      a small search tree. LLVM already has support for lowering switches in
      this way and the first step of this patch is to disable jump-table
      lowering of switches and introduce a pass to rewrite explicit indirectbr
      sequences into a switch over integers.
      
      However, there is no fully general alternative to indirect calls. We
      introduce a new construct we call a "retpoline" to implement indirect
      calls in a non-speculatable way. It can be thought of loosely as
      a trampoline for indirect calls which uses the RET instruction on x86.
      Further, we arrange for a specific call->ret sequence which ensures the
      processor predicts the return to go to a controlled, known location. The
      retpoline then "smashes" the return address pushed onto the stack by the
      call with the desired target of the original indirect call. The result
      is a predicted return to the next instruction after a call (which can be
      used to trap speculative execution within an infinite loop) and an
      actual indirect branch to an arbitrary address.
      
      On 64-bit x86 ABIs, this is especially easily done in the compiler by
      using a guaranteed scratch register to pass the target into this device.
      For 32-bit ABIs there isn't a guaranteed scratch register and so several
      different retpoline variants are introduced to use a scratch register if
      one is available in the calling convention and to otherwise use direct
      stack push/pop sequences to pass the target address.
      
      This "retpoline" mitigation is fully described in the following blog
      post: https://support.google.com/faqs/answer/7625886
      
      We also support a target feature that disables emission of the retpoline
      thunk by the compiler to allow for custom thunks if users want them.
      These are particularly useful in environments like kernels that
      routinely do hot-patching on boot and want to hot-patch their thunk to
      different code sequences. They can write this custom thunk 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 in
      the 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 ELF
      binaries: the PLT. These patches also include support for LLD to
      generate PLT entries that perform a retpoline-style indirection.
      
      The only other indirect branches remaining that we are aware of are from
      precompiled runtimes (such as crt0.o and similar). The ones we have
      found are not really attackable, and so we have not focused on them
      here, but eventually these runtimes should also be replicated for
      retpoline-ed configurations for completeness.
      
      For kernels or other freestanding or fully static executables, the
      compiler switch `-mretpoline` is sufficient to fully mitigate this
      particular attack. For dynamic executables, you must compile *all*
      libraries with `-mretpoline` and additionally link the dynamic
      executable and all shared libraries with LLD and pass `-z retpolineplt`
      (or use similar functionality from some other linker). We strongly
      recommend also using `-z now` as non-lazy binding allows the
      retpoline-mitigated PLT to be substantially smaller.
      
      When manually apply similar transformations to `-mretpoline` to the
      Linux kernel we observed very small performance hits to applications
      running typical workloads, and relatively minor hits (approximately 2%)
      even for extremely syscall-heavy applications. This is largely due to
      the small number of indirect branches that occur in performance
      sensitive paths of the kernel.
      
      When using these patches on statically linked applications, especially
      C++ applications, you should expect to see a much more dramatic
      performance hit. For microbenchmarks that are switch, indirect-, or
      virtual-call heavy we have seen overheads ranging from 10% to 50%.
      
      However, real-world workloads exhibit substantially lower performance
      impact. Notably, techniques such as PGO and ThinLTO dramatically reduce
      the impact of hot indirect calls (by speculatively promoting them to
      direct calls) and allow optimized search trees to be used to lower
      switches. If you need to deploy these techniques in C++ applications, we
      *strongly* recommend that you ensure all hot call targets are statically
      linked (avoiding PLT indirection) and use both PGO and ThinLTO. Well
      tuned servers using all of these techniques saw 5% - 10% overhead from
      the use of retpoline.
      
      We will add detailed documentation covering these components in
      subsequent patches, but wanted to make the core functionality available
      as soon as possible. Happy for more code review, but we'd really like to
      get these patches landed and backported ASAP for obvious reasons. We're
      planning to backport this to both 6.0 and 5.0 release streams and get
      a 5.0 release with just this cherry picked ASAP 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 commit due to the time
      sensitive nature of landing this and the need to backport it. Huge thanks to
      everyone who helped out here, and everyone at Intel who helped out in
      discussions about how to craft this. Also, credit goes to Paul Turner (at
      Google, but not an LLVM contributor) for much of the underlying retpoline
      design.
      
      Reviewers: echristo, rnk, ruiu, craig.topper, DavidKreitzer
      
      Subscribers: sanjoy, emaste, mcrosier, mgorny, mehdi_amini, hiraditya, llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D41723
      ------------------------------------------------------------------------
      
      llvm-svn: 324025
      ff3a8f17
    • Reid Kleckner's avatar
      Merging r323155: · f94a9846
      Reid Kleckner authored
      ```---------------------------------------------------------------------
      r323155 | chandlerc | 2018-01-22 14:05:25 -0800 (Mon, 22 Jan 2018) | 133 lines
      
      Introduce the "retpoline" x86 mitigation technique for variant #2 of the 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 that this
      is a very incomplete description, please see the Project Zero blog post
      for details:
      https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
      
      The basis for branch target injection is to direct speculative execution
      of the processor to some "gadget" of executable code by poisoning the
      prediction of indirect branches with the address of that gadget. The
      gadget in turn contains an operation that provides a side channel for
      reading data. Most commonly, this will look like a load of secret data
      followed by a branch on the loaded value and then a load of some
      predictable cache line. The attacker then uses timing of the processors
      cache to determine which direction the branch took *in the speculative
      execution*, and in turn what one bit of the loaded value was. Due to the
      nature of these timing side channels and the branch predictor on Intel
      processors, this allows an attacker to leak 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 indirect
      branch that could have its prediction poisoned by an attacker. In many
      cases, the compiler can simply use directed conditional branches and
      a small search tree. LLVM already has support for lowering switches in
      this way and the first step of this patch is to disable jump-table
      lowering of switches and introduce a pass to rewrite explicit indirectbr
      sequences into a switch over integers.
      
      However, there is no fully general alternative to indirect calls. We
      introduce a new construct we call a "retpoline" to implement indirect
      calls in a non-speculatable way. It can be thought of loosely as
      a trampoline for indirect calls which uses the RET instruction on x86.
      Further, we arrange for a specific call->ret sequence which ensures the
      processor predicts the return to go to a controlled, known location. The
      retpoline then "smashes" the return address pushed onto the stack by the
      call with the desired target of the original indirect call. The result
      is a predicted return to the next instruction after a call (which can be
      used to trap speculative execution within an infinite loop) and an
      actual indirect branch to an arbitrary address.
      
      On 64-bit x86 ABIs, this is especially easily done in the compiler by
      using a guaranteed scratch register to pass the target into this device.
      For 32-bit ABIs there isn't a guaranteed scratch register and so several
      different retpoline variants are introduced to use a scratch register if
      one is available in the calling convention and to otherwise use direct
      stack push/pop sequences to pass the target address.
      
      This "retpoline" mitigation is fully described in the following blog
      post: https://support.google.com/faqs/answer/7625886
      
      We also support a target feature that disables emission of the retpoline
      thunk by the compiler to allow for custom thunks if users want them.
      These are particularly useful in environments like kernels that
      routinely do hot-patching on boot and want to hot-patch their thunk to
      different code sequences. They can write this custom thunk 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 in
      the 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 ELF
      binaries: the PLT. These patches also include support for LLD to
      generate PLT entries that perform a retpoline-style indirection.
      
      The only other indirect branches remaining that we are aware of are from
      precompiled runtimes (such as crt0.o and similar). The ones we have
      found are not really attackable, and so we have not focused on them
      here, but eventually these runtimes should also be replicated for
      retpoline-ed configurations for completeness.
      
      For kernels or other freestanding or fully static executables, the
      compiler switch `-mretpoline` is sufficient to fully mitigate this
      particular attack. For dynamic executables, you must compile *all*
      libraries with `-mretpoline` and additionally link the dynamic
      executable and all shared libraries with LLD and pass `-z retpolineplt`
      (or use similar functionality from some other linker). We strongly
      recommend also using `-z now` as non-lazy binding allows the
      retpoline-mitigated PLT to be substantially smaller.
      
      When manually apply similar transformations to `-mretpoline` to the
      Linux kernel we observed very small performance hits to applications
      running typical workloads, and relatively minor hits (approximately 2%)
      even for extremely syscall-heavy applications. This is largely due to
      the small number of indirect branches that occur in performance
      sensitive paths of the kernel.
      
      When using these patches on statically linked applications, especially
      C++ applications, you should expect to see a much more dramatic
      performance hit. For microbenchmarks that are switch, indirect-, or
      virtual-call heavy we have seen overheads ranging from 10% to 50%.
      
      However, real-world workloads exhibit substantially lower performance
      impact. Notably, techniques such as PGO and ThinLTO dramatically reduce
      the impact of hot indirect calls (by speculatively promoting them to
      direct calls) and allow optimized search trees to be used to lower
      switches. If you need to deploy these techniques in C++ applications, we
      *strongly* recommend that you ensure all hot call targets are statically
      linked (avoiding PLT indirection) and use both PGO and ThinLTO. Well
      tuned servers using all of these techniques saw 5% - 10% overhead from
      the use of retpoline.
      
      We will add detailed documentation covering these components in
      subsequent patches, but wanted to make the core functionality available
      as soon as possible. Happy for more code review, but we'd really like to
      get these patches landed and backported ASAP for obvious reasons. We're
      planning to backport this to both 6.0 and 5.0 release streams and get
      a 5.0 release with just this cherry picked ASAP 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 commit due to the time
      sensitive nature of landing this and the need to backport it. Huge thanks to
      everyone who helped out here, and everyone at Intel who helped out in
      discussions about how to craft this. Also, credit goes to Paul Turner (at
      Google, but not an LLVM contributor) for much of the underlying retpoline
      design.
      
      Reviewers: echristo, rnk, ruiu, craig.topper, DavidKreitzer
      
      Subscribers: sanjoy, emaste, mcrosier, mgorny, mehdi_amini, hiraditya, llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D41723
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 324012
      f94a9846
    • Reid Kleckner's avatar
      Merging r323915: · e68de238
      Reid Kleckner authored
      ```---------------------------------------------------------------------
      r323915 | chandlerc | 2018-01-31 12:56:37 -0800 (Wed, 31 Jan 2018) | 17 lines
      
      [x86] Make the retpoline thunk insertion a machine function pass.
      
      Summary:
      This removes the need for a machine module pass using some deeply
      questionable hacks. This should address PR36123 which is a case where in
      full LTO the memory usage of a machine module pass actually ended up
      being significant.
      
      We should revert this on trunk as soon as we understand and fix the
      memory usage issue, but we should include this in any backports of
      retpolines themselves.
      
      Reviewers: echristo, MatzeB
      
      Subscribers: sanjoy, mcrosier, mehdi_amini, hiraditya, llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D42726
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 324009
      e68de238
    • Reid Kleckner's avatar
      Merging r323155: · 507d5d8e
      Reid Kleckner authored
      ```---------------------------------------------------------------------
      r323155 | chandlerc | 2018-01-22 14:05:25 -0800 (Mon, 22 Jan 2018) | 133 lines
      
      Introduce the "retpoline" x86 mitigation technique for variant #2 of the 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 that this
      is a very incomplete description, please see the Project Zero blog post
      for details:
      https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
      
      The basis for branch target injection is to direct speculative execution
      of the processor to some "gadget" of executable code by poisoning the
      prediction of indirect branches with the address of that gadget. The
      gadget in turn contains an operation that provides a side channel for
      reading data. Most commonly, this will look like a load of secret data
      followed by a branch on the loaded value and then a load of some
      predictable cache line. The attacker then uses timing of the processors
      cache to determine which direction the branch took *in the speculative
      execution*, and in turn what one bit of the loaded value was. Due to the
      nature of these timing side channels and the branch predictor on Intel
      processors, this allows an attacker to leak 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 indirect
      branch that could have its prediction poisoned by an attacker. In many
      cases, the compiler can simply use directed conditional branches and
      a small search tree. LLVM already has support for lowering switches in
      this way and the first step of this patch is to disable jump-table
      lowering of switches and introduce a pass to rewrite explicit indirectbr
      sequences into a switch over integers.
      
      However, there is no fully general alternative to indirect calls. We
      introduce a new construct we call a "retpoline" to implement indirect
      calls in a non-speculatable way. It can be thought of loosely as
      a trampoline for indirect calls which uses the RET instruction on x86.
      Further, we arrange for a specific call->ret sequence which ensures the
      processor predicts the return to go to a controlled, known location. The
      retpoline then "smashes" the return address pushed onto the stack by the
      call with the desired target of the original indirect call. The result
      is a predicted return to the next instruction after a call (which can be
      used to trap speculative execution within an infinite loop) and an
      actual indirect branch to an arbitrary address.
      
      On 64-bit x86 ABIs, this is especially easily done in the compiler by
      using a guaranteed scratch register to pass the target into this device.
      For 32-bit ABIs there isn't a guaranteed scratch register and so several
      different retpoline variants are introduced to use a scratch register if
      one is available in the calling convention and to otherwise use direct
      stack push/pop sequences to pass the target address.
      
      This "retpoline" mitigation is fully described in the following blog
      post: https://support.google.com/faqs/answer/7625886
      
      We also support a target feature that disables emission of the retpoline
      thunk by the compiler to allow for custom thunks if users want them.
      These are particularly useful in environments like kernels that
      routinely do hot-patching on boot and want to hot-patch their thunk to
      different code sequences. They can write this custom thunk 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 in
      the 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 ELF
      binaries: the PLT. These patches also include support for LLD to
      generate PLT entries that perform a retpoline-style indirection.
      
      The only other indirect branches remaining that we are aware of are from
      precompiled runtimes (such as crt0.o and similar). The ones we have
      found are not really attackable, and so we have not focused on them
      here, but eventually these runtimes should also be replicated for
      retpoline-ed configurations for completeness.
      
      For kernels or other freestanding or fully static executables, the
      compiler switch `-mretpoline` is sufficient to fully mitigate this
      particular attack. For dynamic executables, you must compile *all*
      libraries with `-mretpoline` and additionally link the dynamic
      executable and all shared libraries with LLD and pass `-z retpolineplt`
      (or use similar functionality from some other linker). We strongly
      recommend also using `-z now` as non-lazy binding allows the
      retpoline-mitigated PLT to be substantially smaller.
      
      When manually apply similar transformations to `-mretpoline` to the
      Linux kernel we observed very small performance hits to applications
      running typical workloads, and relatively minor hits (approximately 2%)
      even for extremely syscall-heavy applications. This is largely due to
      the small number of indirect branches that occur in performance
      sensitive paths of the kernel.
      
      When using these patches on statically linked applications, especially
      C++ applications, you should expect to see a much more dramatic
      performance hit. For microbenchmarks that are switch, indirect-, or
      virtual-call heavy we have seen overheads ranging from 10% to 50%.
      
      However, real-world workloads exhibit substantially lower performance
      impact. Notably, techniques such as PGO and ThinLTO dramatically reduce
      the impact of hot indirect calls (by speculatively promoting them to
      direct calls) and allow optimized search trees to be used to lower
      switches. If you need to deploy these techniques in C++ applications, we
      *strongly* recommend that you ensure all hot call targets are statically
      linked (avoiding PLT indirection) and use both PGO and ThinLTO. Well
      tuned servers using all of these techniques saw 5% - 10% overhead from
      the use of retpoline.
      
      We will add detailed documentation covering these components in
      subsequent patches, but wanted to make the core functionality available
      as soon as possible. Happy for more code review, but we'd really like to
      get these patches landed and backported ASAP for obvious reasons. We're
      planning to backport this to both 6.0 and 5.0 release streams and get
      a 5.0 release with just this cherry picked ASAP 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 commit due to the time
      sensitive nature of landing this and the need to backport it. Huge thanks to
      everyone who helped out here, and everyone at Intel who helped out in
      discussions about how to craft this. Also, credit goes to Paul Turner (at
      Google, but not an LLVM contributor) for much of the underlying retpoline
      design.
      
      Reviewers: echristo, rnk, ruiu, craig.topper, DavidKreitzer
      
      Subscribers: sanjoy, emaste, mcrosier, mgorny, mehdi_amini, hiraditya, llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D41723
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 324007
      507d5d8e
  5. 06 Dec, 2017 1 commit
    • Tom Stellard's avatar
      Merging r312509: · c8574de3
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r312509 | dannyb | 2017-09-04 19:17:42 -0700 (Mon, 04 Sep 2017) | 1 line
      
      NewGVN: Fix PR 34452 by passing instruction all the way down when we do aggregate value simplification
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 319952
      c8574de3
  6. 05 Dec, 2017 3 commits
    • Tom Stellard's avatar
      Merging r314733: · 7b938627
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r314733 | rsmith | 2017-10-02 15:43:36 -0700 (Mon, 02 Oct 2017) | 5 lines
      
      PR33839: Fix -Wunused handling for structured binding declarations.
      
      We warn about a structured binding declaration being unused only if none of its
      bindings are used.
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 319847
      7b938627
    • Tom Stellard's avatar
      Merging r314107: · adb004d9
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r314107 | sylvestre | 2017-09-25 07:08:35 -0700 (Mon, 25 Sep 2017) | 9 lines
      
      Fix clangd when built with LLVM_LINK_LLVM_DYLIB=ON
      
      Reviewers: malaperle, malaperle-ericsson, bkramer
      
      Reviewed By: bkramer
      
      Subscribers: bkramer, mgorny, ilya-biryukov, cfe-commits
      
      Differential Revision: https://reviews.llvm.org/D38228
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 319846
      adb004d9
    • Tom Stellard's avatar
      Merging r311734: · d5cd8bc9
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r311734 | ruiu | 2017-08-24 16:51:40 -0700 (Thu, 24 Aug 2017) | 44 lines
      
      [MACH-O] Fix the ASM code generated for __stub_helpers section
      
      Patch by Patricio Villalobos.
      
      I discovered that lld for darwin is generating the wrong code for lazy
      bindings in the __stub_helper section (at least for osx 10.12). This is
      the way i can reproduce this problem, using this program:
      
        #include <stdio.h>
      
        int main(int argc, char **argv) {
            printf("C: printf!\n");
            puts("C: puts!\n");
            return 0;
        }
      
      Then I link it using i have tested it in 3.9, 4.0 and 4.1 versions:
      
        $ clang -c hello.c
        $ lld -flavor darwin hello.o -o h1  -lc
      
      When i execute the binary h1 the system gives me the following error:
      
        C: printf!
        dyld: lazy symbol binding failed:
        BIND_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB
        has segment 4 which is too large (0..3)
        dyld: BIND_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB has segment 4 which is too
        large (0..3)
        Trace/BPT trap: 5
      
      Investigating the code, it seems that the problem is that the asm code
      generated in the file StubPass.cpp, specifically in the line 323,when it
      adds, what it seems an arbitrary number (12) to the offset into the lazy
      bind opcodes section, but it should be calculated depending on the
      MachONormalizedFileBinaryWrite::lazyBindingInfo result.
      
      I confirmed this bug by patching the code manually in the binary and
      writing the right offset in the asm code (__stub_helper).
      
      This patch fixes the content of the atom that contains the assembly code
      when the offset is known.
      
      Differential Revision: https://reviews.llvm.org/D35387
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 319825
      d5cd8bc9
  7. 03 Dec, 2017 1 commit
  8. 28 Nov, 2017 3 commits
    • Tom Stellard's avatar
      Merging r316035: · 1254c70d
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r316035 | tnorthover | 2017-10-17 14:43:52 -0700 (Tue, 17 Oct 2017) | 6 lines
      
      AArch64: account for possible frame index operand in compares.
      
      If the address of a local is used in a comparison, AArch64 can fold the
      address-calculation into the comparison via "adds". Unfortunately, a couple of
      places (both hit in this one test) are not ready to deal with that yet and just
      assume the first source operand is a register.
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 319231
      1254c70d
    • Tom Stellard's avatar
      Merging r319130: · 041898d2
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r319130 | matze | 2017-11-27 17:17:52 -0800 (Mon, 27 Nov 2017) | 7 lines
      
      ARM: Fix PR32578
      
      https://llvm.org/PR32578
      
      I simplified and converted the reproducer into a lit test.
      
      Patch by Vedant Kumar!
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 319181
      041898d2
    • Tom Stellard's avatar
      Merging r311456: · 6a66741f
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r311456 | krasimir | 2017-08-22 07:28:01 -0700 (Tue, 22 Aug 2017) | 13 lines
      
      [clang-format] Fix lines regression in clang-format.py
      
      Summary:
      This patch fixes a regression after https://reviews.llvm.org/rL305665,
      which updates the structure of the `lines` variable.
      
      Reviewers: djasper
      
      Reviewed By: djasper
      
      Subscribers: cfe-commits
      
      Differential Revision: https://reviews.llvm.org/D37011
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 319179
      6a66741f
  9. 27 Nov, 2017 4 commits
    • Tom Stellard's avatar
      Merging r318848: · 0c60ce13
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r318848 | hahnfeld | 2017-11-22 09:15:20 -0800 (Wed, 22 Nov 2017) | 7 lines
      
      Fix for OMP doacross implementation on Power
      
      Power has a weak consistency model so we need memory barriers to
      make writes (both from runtime and from user code) available for
      all threads.
      
      Differential Revision: https://reviews.llvm.org/D40175
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 319057
      0c60ce13
    • Tom Stellard's avatar
      Merging r318658: · c510d367
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r318658 | achurbanov | 2017-11-20 08:00:42 -0800 (Mon, 20 Nov 2017) | 4 lines
      
      Fixed OMP doacross implementation on 32-bit platforms.
      
      Differential Revision: https://reviews.llvm.org/D40171
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 319053
      c510d367
    • Tom Stellard's avatar
      Merging r316106: · 786065d5
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r316106 | labath | 2017-10-18 11:52:16 -0700 (Wed, 18 Oct 2017) | 4 lines
      
      lldb-server tests: Fix undefined behavior
      
      We were creating a StringRef pointing to a temporary string. Problem manifested
      itself when running the test on osx.
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 319035
      786065d5
    • Tom Stellard's avatar
      Merging r316181: · 3f76a35b
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r316181 | jvesely | 2017-10-19 13:40:13 -0700 (Thu, 19 Oct 2017) | 4 lines
      
      AMDGPU: Parse r600 CPU name early and expose FMAF capability
      
      Improve amdgcn macro test
      Differential Revision: https://reviews.llvm.org/D38667
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 319032
      3f76a35b
  10. 22 Nov, 2017 7 commits
    • Tom Stellard's avatar
      Merging r313182: · 2030ade1
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r313182 | sylvestre | 2017-09-13 13:03:29 -0700 (Wed, 13 Sep 2017) | 13 lines
      
      SplitEmptyFunction should be true in the Mozilla coding style
      
      Summary:
      As defined here: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Classes
      See for the downstream bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=1399359
      
      Reviewers: Typz, djasper
      
      Reviewed By: Typz
      
      Subscribers: klimek, cfe-commits
      
      Differential Revision: https://reviews.llvm.org/D37795
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 318858
      2030ade1
    • Tom Stellard's avatar
      Merging r318788: · 3d27c09b
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r318788 | mcrosier | 2017-11-21 10:08:34 -0800 (Tue, 21 Nov 2017) | 16 lines
      
      [AArch64] Mark mrs of TPIDR_EL0 (thread pointer) as *having* side effects.
      
      This partially reverts r298851.  The the underlying issue is that we don't
      currently model the dependency between mrs (read system register) and
      msr (write system register) instructions.
      
      Something like the below should never be reordered:
      
       msr TPIDR_EL0, x0  ;; set thread pointer
       mrs x8, TPIDR_EL0  ;; read thread pointer
      
      but was being reordered after r298851.  The functional part of the patch
      that wasn't reverted needed to remain in place in order to not break
      r299462.
      
      PR35317
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 318854
      3d27c09b
    • Tom Stellard's avatar
      Merging r315086: · 6f6353af
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r315086 | compnerd | 2017-10-06 11:06:59 -0700 (Fri, 06 Oct 2017) | 8 lines
      
      Bitcode: add an auto-upgrade for LTO section name
      
      The bitcode reader looks specifically for `__DATA, __objc_catlist` as a
      section name.  However, SVN r304661 removed the spaces (the two names
      are functionally equivalent but do not compare equally
      lexicographically).  This causes compatibility issues.  Add an
      auto-upgrade path for removing the spaces as well as use the new name in
      the LTO plugin.
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 318851
      6f6353af
    • Tom Stellard's avatar
      Merging r313398: · b45efad4
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r313398 | steven_wu | 2017-09-15 14:12:14 -0700 (Fri, 15 Sep 2017) | 19 lines
      
      [AutoUpgrade] Fix a compatibility issue with module flag
      
      Summary:
      After r304661, module flag to record objective-c image info section is
      encoded without whitespaces after comma. The new name is equivalent to
      the old one, except that when LTO a module built by old compiler and a
      module built by a new compiler, it will fail with conflicting values.
      
      Fix the issue by removing whitespaces in bitcode upgrade path.
      
      rdar://problem/34416934
      
      Reviewers: compnerd
      
      Reviewed By: compnerd
      
      Subscribers: mehdi_amini, hans, llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D37909
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 318850
      b45efad4
    • Tom Stellard's avatar
      Merging r318039: · f0cacaaa
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r318039 | labath | 2017-11-13 06:03:17 -0800 (Mon, 13 Nov 2017) | 37 lines
      
      Revert "[lldb] Use OrcMCJITReplacement rather than MCJIT as the underlying JIT for LLDB"
      
      This commit really did not introduce any functional changes (for most
      people) but it turns out it's not for the reason we thought it was.
      
      The reason wasn't that Orc is a perfect drop-in replacement for MCJIT,
      but it was because we were never using Orc in the first place, as it was
      not initialized.
      
      Orc's initialization relies on a global constructor in the LLVMOrcJIT.a.
      Since this archive does not expose any symbols referenced from other
      object files, it does not get linked into liblldb when linking against
      llvm components statically. However, in an LLVM_LINK_LLVM_DYLIB=On
      build, LLVMOrcJit.a is linked into libLLVM.so using --whole-archive, so
      the global constructor does end up firing.
      
      The result of using Orc jit is pr34194, where lldb fails to evaluate
      even very simple expressions. This bug can be reproduced in
      non-LLVM_LINK_LLVM_DYLIB builds by making sure Orc jit is linked into
      liblldb, for example by #including
      llvm/ExecutionEngine/OrcMCJITReplacement.h in IRExecutionUnit.cpp (and
      adding OrcJIT as a dependency to the relevant CMakeLists.txt file). The
      bug reproduces (at least) on linux and osx.
      
      The root cause of the bug seems to be related to relocation processing.
      It seems Orc processes relocations earlier than the system it is
      replacing. This means the relocation processing happens before we have
      had a chance to remap section load addresses to reflect their address in
      the target process memory, so they end up pointing to locations in the
      lldb's address space instead.
      
      I am not sure whether this is a bug in Orc jit, or in how we are using
      it from lldb, but in any case it is preventing us from using Orc right
      now. Reverting this fixes LLVM_LINK_LLVM_DYLIB build, and makes it clear
      that we are in fact *not* using Orc, and we never really were.
      
      This reverts commit r279327.
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 318845
      f0cacaaa
    • Tom Stellard's avatar
      Merging r315994: · 1d452319
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r315994 | ericwf | 2017-10-17 06:03:17 -0700 (Tue, 17 Oct 2017) | 18 lines
      
      [libc++] Fix PR34898 - vector iterator constructors and assign method perform push_back instead of emplace_back.
      
      Summary:
      The constructors `vector(Iter, Iter, Alloc = Alloc{})` and `assign(Iter, Iter)` don't correctly perform EmplaceConstruction from the result of dereferencing the iterator. This results in them performing an additional and unneeded copy.
      
      This patch addresses the issue by correctly using `emplace_back` in C++11 and newer.
      
      There are also some bugs in our `insert` implementation, but those will be handled separately.
      
      @mclow.lists We should probably merge this into 5.1, agreed?
      
      Reviewers: mclow.lists, dlj, EricWF
      
      Reviewed By: mclow.lists, EricWF
      
      Subscribers: cfe-commits, mclow.lists
      
      Differential Revision: https://reviews.llvm.org/D38757
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 318837
      1d452319
    • Tom Stellard's avatar
      Merging r312892: · 8c2d95c8
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r312892 | ericwf | 2017-09-10 16:41:20 -0700 (Sun, 10 Sep 2017) | 10 lines
      
      Fix PR34298 - Allow std::function with an incomplete return type.
      
      This patch fixes llvm.org/PR34298. Previously libc++ incorrectly evaluated
      the __invokable trait via the converting constructor `function(Tp)` [with Tp = std::function]
      whenever the copy constructor or copy assignment operator
      was required. This patch further constrains that constructor to short
      circut before evaluating the troublesome SFINAE when `Tp` matches
      std::function.
      
      The original patch is from Alex Lorenz.
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 318835
      8c2d95c8
  11. 17 Nov, 2017 1 commit
    • Tom Stellard's avatar
      Merging r318289: · 406ca546
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r318289 | jdevlieghere | 2017-11-15 02:57:05 -0800 (Wed, 15 Nov 2017) | 14 lines
      
      [DebugInfo] Fix potential CU mismatch for SubprogramScopeDIEs.
      
      In constructAbstractSubprogramScopeDIE there can be a potential mismatch
      between `this` and the CU of ContextDIE when a scope is shared between
      two DISubprograms belonging to a different CU. In that case, `this` is
      the CU that was specified in the IR, but the CU of ContextDIE is that of
      the first subprogram that was emitted. This patch fixes the mismatch by
      looking up the CU of ContextDIE, and switching to use that.
      
      This fixes PR35212 (https://bugs.llvm.org/show_bug.cgi?id=35212)
      
      Patch by Philip Craig!
      
      Differential revision: https://reviews.llvm.org/D39981
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 318542
      406ca546
  12. 16 Nov, 2017 1 commit
    • Simon Dardis's avatar
      Merging r318207: · b4d5c651
      Simon Dardis authored
      ```---------------------------------------------------------------------
      r318207 | sdardis | 2017-11-14 22:26:42 +0000 (Tue, 14 Nov 2017) | 18 lines
      
      Reland "[mips][mt][6/7] Add support for mftr, mttr instructions."
      
      This adjusts the tests to hopfully pacify the
      llvm-clang-x86_64-expensive-checks-win buildbot.
      
      Unlike many other instructions, these instructions have aliases which
      take coprocessor registers, gpr register, accumulator (and dsp accumulator)
      registers, floating point registers, floating point control registers and
      coprocessor 2 data and control operands.
      
      For the moment, these aliases are treated as pseudo instructions which are
      expanded into the underlying instruction. As a result, disassembling these
      instructions shows the underlying instruction and not the alias.
      
      Reviewers: slthakur, atanasyan
      
      Differential Revision: https://reviews.llvm.org/D35253
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 318386
      b4d5c651
  13. 15 Nov, 2017 6 commits
    • Tom Stellard's avatar
      Merging r312748: · 5c325eae
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r312748 | jroelofs | 2017-09-07 15:01:25 -0700 (Thu, 07 Sep 2017) | 10 lines
      
      Fix validation of the -mthread-model flag in the Clang driver
      
      The ToolChain class validates the -mthread-model flag in the constructor which
      doesn't work correctly since the thread model methods are virtual methods. The
      check is moved into Clang::ConstructJob() when constructing the internal
      command line.
      
      https://reviews.llvm.org/D37496
      
      Patch by: Ian Tessier!
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 318346
      5c325eae
    • Tom Stellard's avatar
      Merging r312043: · 1e07f078
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r312043 | rnk | 2017-08-29 14:44:21 -0700 (Tue, 29 Aug 2017) | 25 lines
      
      [cmake] Stop putting the revision info in LLVM_VERSION_STRING
      
      Summary:
      This reduces the number of build actions after a no-op commit from
      thousands to about six, which should be acceptable. If six actions is
      still too many, developers can disable the LLVM_APPEND_VC_REV cmake
      option.
      
      llvm-config.h is a widely included header that should rarely change.
      Before this patch, it would change after every re-configure. Very few
      users of llvm-config.h need to know the precise version, and those that
      do can migrate to incorporating LLVM_REVISION as provided by
      llvm/Support/VCSRevision.h.
      
      This should bring LLVM back to the behavior that it had before r306858
      from June 30 2017. Most LLVM tools will now print a version string like
      "6.0.0svn" instead of "6.0.0-git-c40c2a23de4".
      
      Fixes PR34308
      
      Reviewers: pcc, rafael, hans
      
      Subscribers: mgorny, llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D37272
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 318344
      1e07f078
    • Tom Stellard's avatar
      Merging r310475: · 3f249e83
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r310475 | belleyb | 2017-08-09 06:47:01 -0700 (Wed, 09 Aug 2017) | 28 lines
      
      [Support] PR33388 - Fix formatv_object move constructor
      
      formatv_object currently uses the implicitly defined move constructor,
      but it is buggy. In typical use-cases, the problem doesn't show-up
      because all calls to the move constructor are elided. Thus, the buggy
      constructors are never invoked.
      
      The issue especially shows-up when code is compiled using the
      -fno-elide-constructors compiler flag. For instance, this is useful when
      attempting to collect accurate code coverage statistics.
      
      The exact issue is the following:
      
      The Parameters data member is correctly moved, thus making the
      parameters occupy a new memory location in the target
      object. Unfortunately, the default copying of the Adapters blindly
      copies the vector of pointers, leaving each of these pointers
      referencing the parameters in the original object instead of the copied
      one. These pointers quickly become dangling when the original object is
      deleted. This quickly leads to crashes.
      
      The solution is to update the Adapters pointers when performing a move.
      The copy constructor isn't useful for format objects and can thus be
      deleted.
      
      This resolves PR33388.
      
      Differential Revision: https://reviews.llvm.org/D34463
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 318333
      3f249e83
    • Tom Stellard's avatar
      Merging r315578: · 7b672917
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r315578 | abataev | 2017-10-12 06:51:32 -0700 (Thu, 12 Oct 2017) | 7 lines
      
      [OPENMP] Fix PR34925: Fix getting thread_id lvalue for inlined regions
      in C.
      
      If we try to get the lvalue for thread_id variables in inlined regions,
      we did not use the correct version of function. Fixed this bug by adding
      overrided version of the function getThreadIDVariableLValue for inlined
      regions.
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 318315
      7b672917
    • Tom Stellard's avatar
      Merging r313776: · 6fd15753
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r313776 | marshall | 2017-09-20 10:34:11 -0700 (Wed, 20 Sep 2017) | 1 line
      
      Fix a bit of UB in __independent_bits_engine. Fixes PR#34663
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 318236
      6fd15753
    • Tom Stellard's avatar
      Merging r315464: · e3d4cdb1
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r315464 | abataev | 2017-10-11 08:29:40 -0700 (Wed, 11 Oct 2017) | 5 lines
      
      [OPENMP] Fix PR34916: Crash on mixing taskloop|tasks directives.
      
      If both taskloop and task directives are used at the same time in one
      program, we may ran into the situation when the particular type for task
      directive is reused for taskloop directives. Patch fixes this problem.
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 318233
      e3d4cdb1