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

  1. 07 Jul, 2020 1 commit
  2. 06 Jul, 2020 1 commit
  3. 26 Jun, 2020 2 commits
    • Eric Fiselier's avatar
      [libc++] Fix recursive instantiation in std::array. · 77d76b71
      Eric Fiselier authored
      The use of the `&& ...` fold expression in std::array's deduction guides
      recursively builds a set of binary operator expressions of depth N where
      `N` is the number of elements in the initializer.
      
      This is problematic because arrays may be large, and instantiation
      depth is limited.
      
      This patch addresses the issue by flattening the SFINAE using
      the existing `__all` type trait.
      
      (cherry picked from commit c6eb584c)
      77d76b71
    • QingShan Zhang's avatar
      [DAGCombine] Check the uses of negated floating constant and remove the hack · 76ceebb0
      QingShan Zhang authored
      PowerPC hits an assertion due to somewhat the same reason as https://reviews.llvm.org/D70975.
      Though there are already some hack, it still failed with some case, when the operand 0 is NOT
      a const fp, it is another fma that with const fp. And that const fp is negated which result in multi-uses.
      
      A better fix is to check the uses of the negated const fp. If there are already use of its negated
      value, we will have benefit as no extra Node is added.
      
      Differential revision: https://reviews.llvm.org/D75501
      
      (cherry picked from commit 3906ae38)
      76ceebb0
  4. 25 Jun, 2020 10 commits
  5. 24 Jun, 2020 18 commits
  6. 23 Jun, 2020 8 commits
    • Denys Petrov's avatar
      [ManagedStatic] Fix build errors with clang-tblgen in Debug mode using MSVC 2019 v16.6 · 28a6713e
      Denys Petrov authored
      After updating MSVS19 from v16.4 to v16.6 I faced with a build errors compiling in Debug mode.
      It complains on clang-tblgen.exe and llvm-tblgen.exe cmd line args.
      VS compiler had a bug. It dynamically creates an object with constexpr ctor in Debug mode. This bug was fixed in VS2019 v16.5.
      A workaround was implemented for that and everything works until v16.5 comes.
      The workaround became irrelevant since v16.5 and caused build errors.
      So I disabled the workaround for VS2019 v16.5 and higher.
      
      This relates to http://llvm.org/PR41367.
      
      Differential Revision: https://reviews.llvm.org/D80433
      
      (cherry picked from commit 46e5c5fe)
      28a6713e
    • Calixte Denizet's avatar
      [compiler-rt] Reduce the number of threads in gcov test to avoid failure · 5ccc104c
      Calixte Denizet authored
      Summary:
      Patch in D78477 introduced a new test for gcov and this test is failing on arm:
       - http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-full-sh/builds/4752/steps/ninja%20check%202/logs/stdio
        - http://lab.llvm.org:8011/builders/clang-cmake-armv7-full/builds/10501/steps/ninja%20check%202/logs/stdio
      So try to fix it in reducing the number of threads.
      
      Reviewers: marco-c
      
      Reviewed By: marco-c
      
      Subscribers: dberris, kristof.beyls, #sanitizers, serge-sans-paille, sylvestre.ledru
      
      Tags: #sanitizers
      
      Differential Revision: https://reviews.llvm.org/D79621
      
      (cherry picked from commit 0da37bed)
      5ccc104c
    • Alina Sbirlea's avatar
      [BasicAA] Make BasicAA a cfg pass. · caa755f9
      Alina Sbirlea authored
      Summary:
      Part of the changes in D44564 made BasicAA not CFG only due to it using
      PhiAnalysisValues which may have values invalidated.
      Subsequent patches (rL340613) appear to have addressed this limitation.
      
      BasicAA should not be invalidated by non-CFG-altering passes.
      A concrete example is MemCpyOpt which preserves CFG, but we are testing
      it invalidates BasicAA.
      
      llvm-dev RFC: https://groups.google.com/forum/#!topic/llvm-dev/eSPXuWnNfzM
      
      Reviewers: john.brawn, sebpop, hfinkel, brzycki
      
      Subscribers: hiraditya, llvm-commits
      
      Tags: #llvm
      
      Differential Revision: https://reviews.llvm.org/D74353
      
      (cherry picked from commit 0cecafd6)
      caa755f9
    • Nemanja Ivanovic's avatar
      [PowerPC] Do not assume operand of ADDI is an immediate · 1f3be0e9
      Nemanja Ivanovic authored
      After pseudo-expansion, we may end up with ADDI (add immediate)
      instructions where the operand is not an immediate but a relocation.
      For such instructions, attempts to get the immediate result in
      assertion failures for obvious reasons.
      
      Fixes: https://bugs.llvm.org/show_bug.cgi?id=45432
      (cherry picked from commit a56d057d)
      1f3be0e9
    • Yonghong Song's avatar
      [BPF] fix incorrect type in BPFISelDAGToDAG readonly load optimization · f5bad9ca
      Yonghong Song authored
      In BPF Instruction Selection DAGToDAG transformation phase,
      BPF backend had an optimization to turn load from readonly data
      section to direct load of the values. This phase is implemented
      before libbpf has readonly section support and before alu32
      is supported.
      
      This phase however may generate incorrect type when alu32 is
      enabled. The following is an example,
        -bash-4.4$ cat ~/tmp2/t.c
        struct t {
          unsigned char a;
          unsigned char b;
          unsigned char c;
        };
        extern void foo(void *);
        int test() {
          struct t v = {
            .b = 2,
          };
          foo(&v);
          return 0;
        }
      
      The compiler will turn local variable "v" into a readonly section.
      During instruction selection phase, the compiler generates two
      loads from readonly section, one 2 byte load or 1 byte load, e.g., for 2 loads,
        t8: i32,ch = load<(dereferenceable load 2 from `i8* getelementptr inbounds
             (%struct.t, %struct.t* @__const.test.v, i64 0, i32 0)`, align 1),
             anyext from i16> t3, GlobalAddress:i64<%struct.t* @__const.test.v> 0, undef:i64
        t9: ch = store<(store 2 into %ir.v1.sub1), trunc to i16> t3, t8,
          FrameIndex:i64<0>, undef:i64
      
      BPF backend changed t8 to i64 = Constant<2> and eventually the generated machine IR:
        t10: i64 = MOV_ri TargetConstant:i64<2>
        t40: i32 = SLL_ri_32 t10, TargetConstant:i32<8>
        t41: i32 = OR_ri_32 t40, TargetConstant:i64<0>
        t9: ch = STH32<Mem:(store 2 into %ir.v1.sub1)> t41, TargetFrameIndex:i64<0>,
            TargetConstant:i64<0>, t3
      
      Note that t10 in the above is not correct. The type should be i32 and instruction
      should be MOV_ri_32. The reason for incorrect insn selection is BPF insn selection
      generated an i64 constant instead of an i32 constant as specified in the original
      load instruction. Such incorrect insn sequence eventually caused the following
      fatal error when a COPY insn tries to copy a 64bit register to a 32bit subregister.
        Impossible reg-to-reg copy
        UNREACHABLE executed at ../lib/Target/BPF/BPFInstrInfo.cpp:42!
      
      This patch fixed the issue by using the load result type instead of always i64
      when doing readonly load optimization.
      
      Differential Revision: https://reviews.llvm.org/D81630
      
      (cherry picked from commit 4db18781)
      f5bad9ca
    • Nico Weber's avatar
      Make LLVM_APPEND_VC_REV=OFF affect clang, lld, and lldb as well. · 0777c907
      Nico Weber authored
      When LLVM_APPEND_VC_REV=OFF is set, the current git hash is no
      longer embedded into binaries (mostly for --version output).
      Without it, most binaries need to relink after every single
      commit, even if they didn't change otherwise (due to, say,
      a documentation-only commit).
      
      LLVM_APPEND_VC_REV is ON by default, so this doesn't change the
      default behavior of anything.
      
      With this, all clients of GenerateVersionFromVCS.cmake honor
      LLVM_APPEND_VC_REV.
      
      Differential Revision: https://reviews.llvm.org/D72855
      
      (cherry picked from commit fb5fafb2)
      0777c907
    • Kadir Cetinkaya's avatar
      [clangd] Fix DocumentOutline for concepts · 97065683
      Kadir Cetinkaya authored
      Summary: Fixes https://github.com/clangd/clangd/issues/256
      
      Reviewers: kbobyrev
      
      Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits
      
      Tags: #clang
      
      Differential Revision: https://reviews.llvm.org/D73056
      
      (cherry picked from commit fb3d9153)
      97065683
    • Yonghong Song's avatar
      [BPF] fix a bug for BTF pointee type pruning · c69ed62e
      Yonghong Song authored
      In BTF, pointee type pruning is used to reduce cluttering
      too many unused types into prog BTF. For example,
         struct task_struct {
            ...
            struct mm_struct *mm;
            ...
         }
      If bpf program does not access members of "struct mm_struct",
      there is no need to bring types for "struct mm_struct" to BTF.
      
      This patch fixed a bug where an incorrect pruning happened.
      The test case like below:
          struct t;
          typedef struct t _t;
          struct s1 { _t *c; };
          int test1(struct s1 *arg) { ... }
      
          struct t { int a; int b; };
          struct s2 { _t c; }
          int test2(struct s2 *arg) { ... }
      
      After processing test1(), among others, BPF backend generates BTF types for
          "struct s1", "_t" and a placeholder for "struct t".
      Note that "struct t" is not really generated. If later a direct access
      to "struct t" member happened, "struct t" BTF type will be generated
      properly.
      
      During processing test2(), when processing member type "_t c",
      BPF backend sees type "_t" already generated, so returned.
      This caused the problem that "struct t" BTF type is never generated and
      eventually causing incorrect type definition for "struct s2".
      
      To fix the issue, during DebugInfo type traversal, even if a
      typedef/const/volatile/restrict derived type has been recorded in BTF,
      if it is not a type pruning candidate, type traversal of its base type continues.
      
      Differential Revision: https://reviews.llvm.org/D82041
      
      (cherry picked from commit 89648eb1)
      c69ed62e