Started 4 mo 23 days ago
Took 4 hr 53 min on green-dragon-19

Success Build #18490 (Jul 22, 2019 5:36:16 PM)

Revisions
  • http://llvm.org/svn/llvm-project/llvm/trunk : 366743
  • http://llvm.org/svn/llvm-project/cfe/trunk : 366719
  • http://llvm.org/svn/llvm-project/compiler-rt/trunk : 366738
  • http://llvm.org/svn/llvm-project/debuginfo-tests/trunk : 364589
  • http://llvm.org/svn/llvm-project/libcxx/trunk : 366735
  • http://llvm.org/svn/llvm-project/clang-tools-extra/trunk : 366698
Changes
  1. AMDGPU: Don't use SDNodeXForm for DS offset output

    The xform has no real valuewhen it's using out of a complex pattern
    output. The complex pattern was already creating TargetConstants with
    i16, so this was just unnecessary machinery.

    This allows global isel to import the simple cases once the complex
    pattern is implemented. (detail/ViewSVN)
    by arsenm
  2. [TSan] Enable fiber tests on iOS simulator

    These tests *do not* work on device, but they *do* work in the
    simulator.

    rdar://53403778 (detail/ViewSVN)
    by yln
  3. Temporarily Revert "[Attributor] Liveness analysis." as it's breaking the build.

    This reverts commit 9285295f75a231dc446fa7cbc10a0a391b3434a5. (detail/ViewSVN)
    by echristo
  4. [Attributor] Liveness analysis.

    Liveness analysis abstract attribute used to indicate which BasicBlocks are dead and can therefore be ignored.
    Right now we are only looking at noreturn calls.

    Reviewers: jdoerfert, uenoku

    Subscribers: hiraditya, llvm-commits

    Differential revision: https://reviews.llvm.org/D64162 (detail/ViewSVN)
    by sstefan
  5. [NFC][libc++] Add missing EXPLICIT to pair and tuple synopsis

    The constructors for std::pair and std::tuple have been made conditionally
    explicit, however the synopsis in the headers do not reflect that. (detail/ViewSVN)
    by Louis Dionne
  6. [runtimes] Don't depend on libpthread on Android

    r362048 added support for ELF dependent libraries, but broke Android
    build since Android does not have libpthread. Remove the dependency on
    the Android build.

    Differential Revision: https://reviews.llvm.org/D65098 (detail/ViewSVN)
    by kongyi
  7. [X86] When using AND+PACKUS in lowerV16I8Shuffle, generate the build vector directly in v16i8 with the correct 0x00 or 0xFF elements rather than using another VT and bitcasting it.

    The build_vector will become a constant pool load. By using the
    desired type initially, it ensures we don't generate a bitcast
    of the constant pool load which will need to be folded with
    the load.

    While experimenting with another patch, I noticed that when the
    load type and the constant pool type don't match, then
    SimplifyDemandedBits can't handle it. While we should probably
    fix that, this was a simple way to fix the issue I saw. (detail/ViewSVN)
    by ctopper
  8. [NFC][PowerPC]Change ADDIStocHA to ADDIStocHA8 to follow 64-bit naming convention

    Summary:

    Since we are planning to add ADDIStocHA for 32bit in later patch, we decided
    to change 64bit one first to follow naming convention with 8 behind opcode.

    Patch by: Xiangling_L

    Differential Revision: https://reviews.llvm.org/D64814 (detail/ViewSVN)
    by jasonliu
  9. [libc++] Set __file_ to 0 in basic_filebuf::close() even if fclose fails

    This issue was detected by ASan in one of our tests. This test manually
    invokes basic_filebuf::cloe(). fclose(__h.release() returned a non-zero
    exit status, so __file_ wasn't set to 0. Later when basic_filebuf
    destructor ran, we would enter the if (__file_) block again leading to
    heap-use-after-free error.

    The POSIX specification for fclose says that independently of the return
    value, fclose closes the underlying file descriptor and any further
    access (including another call to fclose()) to the stream results in
    undefined behavior. This is exactly what happened in our test case.

    To avoid this issue, we have to always set __file_ to 0 independently of
    the fclose return value.

    Differential Revision: https://reviews.llvm.org/D64979 (detail/ViewSVN)
    by phosek
  10. [Attributor] NoAlias on return values.

    Porting function return value attribute noalias to attributor.
    This will be followed with a patch for callsite and function argumets.

    Reviewers: jdoerfert

    Subscribers: lebedev.ri, hiraditya, llvm-commits

    Differential Revision: https://reviews.llvm.org/D63067 (detail/ViewSVN)
    by sstefan
  11. Stubs out TLOF for AIX and add support for common vars in assembly output.

    Stubs out a TargetLoweringObjectFileXCOFF class, implementing only
    SelectSectionForGlobal for common symbols. Also adds an override of
    EmitGlobalVariable in PPCAIXAsmPrinter which adds a number of defensive errors
    and adds support for emitting common globals. (detail/ViewSVN)
    by sfertile
  12. [SafeStack] Insert the deref after the offset

    While debugging code that uses SafeStack, we've noticed that LLVM
    produces an invalid DWARF. Concretely, in the following example:

      int main(int argc, char* argv[]) {
        std::string value = "";
        printf("%s\n", value.c_str());
        return 0;
      }

    DWARF would describe the value variable as being located at:

      DW_OP_breg14 R14+0, DW_OP_deref, DW_OP_constu 0x20, DW_OP_minus

    The assembly to get this variable is:

      leaq    -32(%r14), %rbx

    The order of operations in the DWARF symbols is incorrect in this case.
    Specifically, the deref is incorrect; this appears to be incorrectly
    re-inserted in repalceOneDbgValueForAlloca.

    With this change which inserts the deref after the offset instead of
    before it, LLVM produces correct DWARF:

      DW_OP_breg14 R14-32

    Differential Revision: https://reviews.llvm.org/D64971 (detail/ViewSVN)
    by phosek
  13. WholeProgramDevirt: Teach the pass to respect the global's alignment.

    The bytes inserted before an overaligned global need to be padded according
    to the alignment set on the original global in order for the initializer
    to meet the global's alignment requirements. The previous implementation
    that padded to the pointer width happened to be correct for vtables on most
    platforms but may do the wrong thing if the vtable has a larger alignment.

    This issue is visible with a prototype implementation of HWASAN for globals,
    which will overalign all globals including vtables to 16 bytes.

    There is also no padding requirement for the bytes inserted after the global
    because they are never read from nor are they significant for alignment
    purposes, so stop inserting padding there.

    Differential Revision: https://reviews.llvm.org/D65031 (detail/ViewSVN)
    by pcc
  14. [PowerPC] Fix comment on MO_PLT Target Operand Flag. [NFC]

    Patch by Xiangling Liao. (detail/ViewSVN)
    by sfertile
  15. [Object][XCOFF] Remove extra includes from XCOFF related files. [NFC]

    Differential Revision: https://reviews.llvm.org/D60885 (detail/ViewSVN)
    by sfertile
  16. LowerTypeTests: Teach the pass to respect global alignments.

    We were previously ignoring alignment entirely when combining globals
    together in this pass. There are two main things that we need to do here:
    add additional padding before each global to meet the alignment requirements,
    and set the combined global's alignment to the maximum of all of the original
    globals' alignments.

    Since we now need to calculate layout as we go anyway, use the calculated
    layout to produce GlobalLayout instead of using StructLayout.

    Differential Revision: https://reviews.llvm.org/D65033 (detail/ViewSVN)
    by pcc
  17. Changes to emit CodeView debug info nested type records properly using MCStreamer directives (detail/ViewSVN)
    by nilanjana_basu
  18. Adds support for formatting NS_CLOSED_ENUM and CF_CLOSED_ENUM alongside NS_ENUM and CF_ENUM.

    Summary:
    Addresses the formatting of NS_CLOSED_ENUM and CF_CLOSED_ENUM, introduced in Swift 5.

    Before:

    ```
    typedef NS_CLOSED_ENUM(NSInteger, Foo){FooValueOne = 1, FooValueTwo,
                                           FooValueThree};
    ```

    After:

    ```
    typedef NS_CLOSED_ENUM(NSInteger, Foo) {
      FooValueOne = 1,
      FooValueTwo,
      FooValueThree
    };
    ```

    Contributed by heijink.

    Reviewers: benhamilton, krasimir

    Reviewed By: benhamilton

    Subscribers: cfe-commits

    Tags: #clang

    Differential Revision: https://reviews.llvm.org/D65012 (detail/ViewSVN)
    by benhamilton
  19. [AMDGPU] Test update. NFC. (detail/ViewSVN)
    by rampitec
  20. [SLPVectorizer] Fix some MSVC/cppcheck uninitialized variable warnings. NFCI. (detail/ViewSVN)
    by rksimon
  21. Revert "Reland [ELF] Loose a condition for relocation with a symbol"

    This reverts commit r366686 as it appears to be causing buildbot
    failures on sanitizer-x86_64-linux-android and sanitizer-x86_64-linux. (detail/ViewSVN)
    by vlad.tsyrklevich
  22. [OPENMP][MSVC]Enable /openmp[:experimental] to compile OpenMP.

    Mapped /openmp[:experimental] to -fopenmp option and /openmp- option to
    -fno-openmp (detail/ViewSVN)
    by abataev
  23. [libc++] Do not infer support for C++17 in GCC < 7

    libc++'s lit configuration infers the C++ language dialect when it is
    not provided by checking which -std= flags that a compiler supports.
    GCC 5 and GCC 6 have a -std=c++17 flag, however, they do not have full
    C++17 support. The lit configuration has hardcoded logic that removes
    -std=c++1z as an option to test for GCC < 7, but not -std=c++17.

    This leads to a bunch of failures when running libc++ tests with GCC 5
    or GCC 6. This patch adds -std=c++17 to the list of flags that are
    discarded for GCC < 7 by lit's language dialect inference.

    Thanks to Bryce Adelstein Lelbach for the patch.

    Differential Revision: https://reviews.llvm.org/D62874 (detail/ViewSVN)
    by Louis Dionne
  24. [X86] Remove const from some intrinsics that shouldn't have them (detail/ViewSVN)
    by probinson
  25. [clangd] Add dlog()s for SelectionTree, enabling -debug-only=SelectionTree.cpp

    Summary:
    SelectionTree is a RecursiveASTVisitor which processes getSourceRange() for
    every node. This is a lot of surface area with the AST, as getSourceRange()
    is specialized for *many* node types.
    And the resulting SelectionTree depends on the source ranges of many
    visited nodes, and the order of traversal.

    Put together, this means we really need a traversal log to debug when we
    get an unexpected SelectionTree. I've built this ad-hoc a few times, now
    it's time to check it in.

    Example output:
    ```
    D[14:07:44.184] Computing selection for </usr/local/google/home/sammccall/test.cc:1:7, col:8>
    D[14:07:44.184]  push: VarDecl const auto x = 42
    D[14:07:44.184]   claimRange: </usr/local/google/home/sammccall/test.cc:1:12, col:13>
    D[14:07:44.184]   push: NestedNameSpecifierLoc (empty NestedNameSpecifierLoc)
    D[14:07:44.184]   pop: NestedNameSpecifierLoc (empty NestedNameSpecifierLoc)
    D[14:07:44.184]   push: QualifiedTypeLoc const auto
    D[14:07:44.184]   pop: QualifiedTypeLoc const auto
    D[14:07:44.184]    claimRange: </usr/local/google/home/sammccall/test.cc:1:7, col:11>
    D[14:07:44.184]    hit selection: </usr/local/google/home/sammccall/test.cc:1:7, col:8>
    D[14:07:44.184]   skip: IntegerLiteral 42
    D[14:07:44.184]    skipped range = </usr/local/google/home/sammccall/test.cc:1:16>
    D[14:07:44.184]  pop: VarDecl const auto x = 42
    D[14:07:44.184]   claimRange: </usr/local/google/home/sammccall/test.cc:1:1, col:18>
    D[14:07:44.184]  skip: VarDecl int y = 43
    D[14:07:44.184]   skipped range = </usr/local/google/home/sammccall/test.cc:2:1, col:9>
    D[14:07:44.184] Built selection tree
    TranslationUnitDecl
      VarDecl const auto x = 42
         .QualifiedTypeLoc const auto

    ```

    Reviewers: hokein

    Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, llvm-commits

    Tags: #llvm

    Differential Revision: https://reviews.llvm.org/D65073 (detail/ViewSVN)
    by sammccall
  26. Update c++2a status page with post-Cologne information (detail/ViewSVN)
    by marshall

Started by upstream project clang-stage2-Rthinlto_relay build number 1898
originally caused by:

This run spent:

  • 3 ms waiting;
  • 4 hr 53 min build duration;
  • 4 hr 53 min total from scheduled to completion.
LLVM/Clang Warnings: 1 warning.
    Test Result (no failures)