Started 10 days ago
Took 30 min

Success Build clang-r365575-t57842-b57842.tar.gz (Jul 9, 2019 5:24:05 PM)

Issues

No known issues detected

Build Log

Revision: 364448
Changes
  1. AMDGPU/GlobalISel: Fix legality for G_BUILD_VECTOR (detail)
    by arsenm
  2. [AMDGPU] gfx908 v_pk_fmac_f16 support

    Differential Revision: https://reviews.llvm.org/D64433 (detail)
    by rampitec
  3. gn build: Merge r365536. (detail)
    by pcc
  4. gn build: Merge r365532. (detail)
    by pcc
  5. gn build: Merge r365541. (detail)
    by pcc
  6. gn build: Merge r365531. (detail)
    by pcc
  7. Add lldb type unit support to the release notes

    Reviewers: JDevlieghere, teemperor

    Subscribers: llvm-commits, lldb-commits

    Tags: #llvm

    Differential Revision: https://reviews.llvm.org/D64366 (detail)
    by labath
  8. GlobalISel: Combine unmerge of merge with intermediate cast

    This eliminates some illegal intermediate vectors when operations are
    scalarized. (detail)
    by arsenm
  9. [Profile] Support raw/indexed profiles larger than 4GB

    rdar://45955976 (detail)
    by Vedant Kumar
  10. [llvm-objdump] Keep warning for --disassemble-functions in correct order.

    relative to normal output when dumping archive files.

    prepare for PR35351.

    Reviewers: jhenderson, grimar, MaskRay, rupprecht

    Reviewed by: MaskRay, jhenderson

    Differential Revision: https://reviews.llvm.org/D64165 (detail)
    by yuanfang
  11. [AMDGPU] gfx908 mAI instructions, MC part

    Differential Revision: https://reviews.llvm.org/D64446 (detail)
    by rampitec
  12. [SLP] Optimize getSpillCost(); NFCI

    For a given set of live values, the spill cost will always be the
    same for each call. Compute the cost once and multiply it by the
    number of calls.

    (I'm not sure this spill cost modeling makes sense if there are
    multiple calls, as the spill cost will likely be shared across
    calls in that case. But that's how it currently works.) (detail)
    by nikic
  13. hwasan: Improve precision of checks using short granule tags.

    A short granule is a granule of size between 1 and `TG-1` bytes. The size
    of a short granule is stored at the location in shadow memory where the
    granule's tag is normally stored, while the granule's actual tag is stored
    in the last byte of the granule. This means that in order to verify that a
    pointer tag matches a memory tag, HWASAN must check for two possibilities:

    * the pointer tag is equal to the memory tag in shadow memory, or
    * the shadow memory tag is actually a short granule size, the value being loaded
      is in bounds of the granule and the pointer tag is equal to the last byte of
      the granule.

    Pointer tags between 1 to `TG-1` are possible and are as likely as any other
    tag. This means that these tags in memory have two interpretations: the full
    tag interpretation (where the pointer tag is between 1 and `TG-1` and the
    last byte of the granule is ordinary data) and the short tag interpretation
    (where the pointer tag is stored in the granule).

    When HWASAN detects an error near a memory tag between 1 and `TG-1`, it
    will show both the memory tag and the last byte of the granule. Currently,
    it is up to the user to disambiguate the two possibilities.

    Because this functionality obsoletes the right aligned heap feature of
    the HWASAN memory allocator (and because we can no longer easily test
    it), the feature is removed.

    Also update the documentation to cover both short granule tags and
    outlined checks.

    Differential Revision: https://reviews.llvm.org/D63908 (detail)
    by pcc
  14. [PoisonChecking] Flesh out complete todo list for full coverage

    Note: I don't actually plan to implement all of the cases at the moment, I'm just documenting them for completeness.  There's a couple of cases left which are practically useful for me in debugging loop transforms, and I'll probably stop there for the moment. (detail)
    by reames
  15. [X86][AMDGPU][DAGCombiner] Move call to allowsMemoryAccess into isLoadBitCastBeneficial/isStoreBitCastBeneficial to allow X86 to bypass it

    Basically the problem is that X86 doesn't set the Fast flag from
    allowsMemoryAccess on certain CPUs due to slow unaligned memory
    subtarget features. This prevents bitcasts from being folded into
    loads and stores. But all vector loads and stores of the same width
    are the same cost on X86.

    This patch merges the allowsMemoryAccess call into isLoadBitCastBeneficial to allow X86 to skip it.

    Differential Revision: https://reviews.llvm.org/D64295 (detail)
    by ctopper
  16. Fix build error for VC STL, use llvm::make_unique (detail)
    by rnk
  17. [AMDGPU] gfx908 register file changes

    Differential Revision: https://reviews.llvm.org/D64438 (detail)
    by rampitec
  18. [PoisonCheker] Support for out of bounds operands on shifts + insert/extractelement

    These are sources of poison which don't come from flags, but are clearly documented in the LangRef.  Left off support for scalable vectors for the moment, but should be easy to add if anyone is interested. (detail)
    by reames
  19. Boilerplate for producing XCOFF object files from the PowerPC backend.

    Stubs out a number of the classes needed to produce a new object file format
    (XCOFF) for the powerpc-aix target. For testing input is an empty module which
    produces an object file with just a file header.

    Differential Revision: https://reviews.llvm.org/D61694 (detail)
    by sfertile
  20. [X86] LowerToHorizontalOp - use count_if to count non-UNDEF ops. NFCI. (detail)
    by rksimon
  21. [PoisonChecking] Add validation rules for "exact" on sdiv/udiv

    As directly stated in the LangRef, no ambiguity here... (detail)
    by reames
  22. [ThinLTO] only emit used or referenced CFI records to index

    Summary: We emit CFI_FUNCTION_DEFS and CFI_FUNCTION_DECLS to
    distributed ThinLTO indices to implement indirect function call
    checking.  This change causes us to only emit entries for functions
    that are either defined or used by the module we're writing the index
    for (instead of all functions in the combined index), which can make
    the indices substantially smaller.

    Fixes PR42378.

    Reviewers: pcc, vitalybuka, eugenis

    Subscribers: mehdi_amini, hiraditya, dexonsmith, arphaman, llvm-commits

    Tags: #llvm

    Differential Revision: https://reviews.llvm.org/D63887 (detail)
    by inglorion
  23. Add a transform pass to make the executable semantics of poison explicit in the IR

    Implements a transform pass which instruments IR such that poison semantics are made explicit. That is, it provides a (possibly partial) executable semantics for every instruction w.r.t. poison as specified in the LLVM LangRef. There are obvious parallels to the sanitizer tools, but this pass is focused purely on the semantics of LLVM IR, not any particular source language.

    The target audience for this tool is developers working on or targetting LLVM from a frontend. The idea is to be able to take arbitrary IR (with the assumption of known inputs), and evaluate it concretely after having made poison semantics explicit to detect cases where either a) the original code executes UB, or b) a transform pass introduces UB which didn't exist in the original program.

    At the moment, this is mostly the framework and still needs to be fleshed out. By reusing existing code we have decent coverage, but there's a lot of cases not yet handled. What's here is good enough to handle interesting cases though; for instance, one of the recent LFTR bugs involved UB being triggered by integer induction variables with nsw/nuw flags would be reported by the current code.

    (See comment in PoisonChecking.cpp for full explanation and context)

    Differential Revision: https://reviews.llvm.org/D64215 (detail)
    by reames
  24. Try to appease the Windows build bots.

    Several of the conditonal operators commited in llvm-svn: 365524 fail to compile
    on the windows buildbots. Converting to an if and early return to try to fix. (detail)
    by sfertile
  25. [BPF] Fix a typo in the file name

    Fixed the file name from BPFAbstrctMemberAccess.cpp to
    BPFAbstractMemberAccess.cpp.

    Signed-off-by: Yonghong Song <yhs@fb.com> (detail)
    by yhs
  26. gn build: Merge r365503. (detail)
    by pcc
  27. [unittest] Add the missing bogus machine register info initialization. (detail)
    by hliao
  28. [AMDGPU] gfx908 target

    Differential Revision: https://reviews.llvm.org/D64429 (detail)
    by rampitec
  29. [Object][XCOFF] Add support for 64-bit file header and section header dumping.

    Adds a readobj dumper for 32-bit and 64-bit section header tables, and extend
    support for the file-header dumping to include 64-bit object files. Also
    refactors the binary file parsing to be done in a helper function in an attempt
    to cleanup error handeling.

    Differential Revision: https://reviews.llvm.org/D63843 (detail)
    by sfertile
  30. [InstCombine] add tests for trunc(load); NFC

    I'm not sure if transforming any of these is valid as
    a target-independent fold, but we might as well have
    a few tests here to confirm or deny our position. (detail)
    by spatel
  31. AMDGPU: Fix test failing since r365512 (detail)
    by arsenm
  32. Revert "[HardwareLoops] NFC - move hardware loop checking code to isHardwareLoopProfitable()"

    This reverts commit d95557306585404893d610784edb3e32f1bfce18. (detail)
    by jsji
  33. Add lit.local.cfg to llvm-objdump tests

    Add configuration file to llvm-objdump tests to treat files with .yaml
    extension as tests. (detail)
    by steven_wu
Revision: 364448
Changes
  1. [clang] DirectoryWatcher

    Asynchronously monitors specified directory for changes and passes notifications to provided callback.

    Dependency for index-while-building.

    Differential Revision: https://reviews.llvm.org/D58418 (detail)
    by Jan Korous
  2. XFAIL clang/test/Headers/max_align.c on i686 (detail)
    by andusy
  3. Use the Itanium C++ ABI for the pipe_builtin.cl test

    Certain OpenCL constructs cannot yet be mangled in the MS C++ ABI.
    Add a FIXME for it if anyone cares to implement it. (detail)
    by rnk
  4. De-templatize non-dependent VS macro logic, NFC

    These macro definitions don't depend on the template parameter, so they
    don't need to be part of the template. Move them to a .cpp file. (detail)
    by rnk
  5. [CXX] Exercise all paths through these tests.

    Differential Revision: https://reviews.llvm.org/D63894 (detail)
    by probinson
  6. hwasan: Improve precision of checks using short granule tags.

    A short granule is a granule of size between 1 and `TG-1` bytes. The size
    of a short granule is stored at the location in shadow memory where the
    granule's tag is normally stored, while the granule's actual tag is stored
    in the last byte of the granule. This means that in order to verify that a
    pointer tag matches a memory tag, HWASAN must check for two possibilities:

    * the pointer tag is equal to the memory tag in shadow memory, or
    * the shadow memory tag is actually a short granule size, the value being loaded
      is in bounds of the granule and the pointer tag is equal to the last byte of
      the granule.

    Pointer tags between 1 to `TG-1` are possible and are as likely as any other
    tag. This means that these tags in memory have two interpretations: the full
    tag interpretation (where the pointer tag is between 1 and `TG-1` and the
    last byte of the granule is ordinary data) and the short tag interpretation
    (where the pointer tag is stored in the granule).

    When HWASAN detects an error near a memory tag between 1 and `TG-1`, it
    will show both the memory tag and the last byte of the granule. Currently,
    it is up to the user to disambiguate the two possibilities.

    Because this functionality obsoletes the right aligned heap feature of
    the HWASAN memory allocator (and because we can no longer easily test
    it), the feature is removed.

    Also update the documentation to cover both short granule tags and
    outlined checks.

    Differential Revision: https://reviews.llvm.org/D63908 (detail)
    by pcc
  7. [OpenMP] Simplify getFloatTypeSemantics

    When the float point representations are the same on the host and on the target device,
    (`&Target->getLongDoubleFormat() == &AuxTarget->getLongDoubleFormat()`),
    we can just use `AuxTarget->getLongDoubleFormat()`.

    Reviewed By: ABataev

    Differential Revision: https://reviews.llvm.org/D64423 (detail)
    by maskray
  8. [AMDGPU] gfx908 clang target

    Differential Revision: https://reviews.llvm.org/D64430 (detail)
    by rampitec
  9. [ObjC] Add a warning for implicit conversions of a constant non-boolean value to BOOL

    rdar://51954400

    Differential revision: https://reviews.llvm.org/D63912 (detail)
    by epilk
Revision: 364448
Changes
  1. [clangd] Rewrite of logic to rebuild the background index serving structures.

    Summary:
    Previously it was rebuilding every 5s by default, which was much too frequent
    in the long run - the goal was to provide an early build. There were also some
    bugs. There were also some bugs, and a dedicated thread was used in production
    but not tested.

    - rebuilds are triggered by #TUs built, rather than time. This should scale
       more sensibly to fast vs slow machines.
    - there are two separate indexed-TU thresholds to trigger index build: 5 TUs
       for the first build, 100 for subsequent rebuilds.
    - rebuild is always done on the regular indexing threads, and is affected by
       blockUntilIdle. This means unit/lit tests run the production configuration.
    - fixed a bug where we'd rebuild after attempting to load shards, even if there
       were no shards.
    - the BackgroundIndexTests don't really test the subtleties of the rebuild
       policy (for determinism, we call blockUntilIdle, so rebuild-on-idle is enough
       to pass the tests). Instead, we expose the rebuilder as a separate class and
       have fine-grained tests for it.

    Reviewers: kadircet

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

    Tags: #llvm

    Differential Revision: https://reviews.llvm.org/D64291 (detail)
    by sammccall
  2. [clangd] Show documentation in hover, and fetch docs from index if needed.

    Summary:
    I assume showing docs is going to be part of structured hover rendering, but
    it's unclear whether that's going to make clangd 9 so this is low-hanging fruit.

    (Also fixes a bug uncovered in FormattedString's plain text output: need blank
    lines when text follows codeblocks)

    Reviewers: kadircet

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

    Tags: #llvm

    Differential Revision: https://reviews.llvm.org/D64296 (detail)
    by sammccall
Revision: 364448
Changes
  1. Reland "[TSan] Improve handling of stack pointer mangling in {set,long}jmp, pt.8"

    Fix compilation errors related to `SANITIZER_GO` `#ifdef`s.

    Refine longjmp key management.  For Linux, re-implement key retrieval in
    C (instead of assembly).  Removal of `InitializeGuardPtr` and a final
    round of cleanups will be done in the next commit.

    Reviewed By: dvyukov

    Differential Revision: https://reviews.llvm.org/D64092

    llvm-svn: 365513 (detail)
    by yln
  2. [TSan] Refine longjmp key management on Darwin

    NFC. (detail)
    by yln
  3. hwasan: Improve precision of checks using short granule tags.

    A short granule is a granule of size between 1 and `TG-1` bytes. The size
    of a short granule is stored at the location in shadow memory where the
    granule's tag is normally stored, while the granule's actual tag is stored
    in the last byte of the granule. This means that in order to verify that a
    pointer tag matches a memory tag, HWASAN must check for two possibilities:

    * the pointer tag is equal to the memory tag in shadow memory, or
    * the shadow memory tag is actually a short granule size, the value being loaded
      is in bounds of the granule and the pointer tag is equal to the last byte of
      the granule.

    Pointer tags between 1 to `TG-1` are possible and are as likely as any other
    tag. This means that these tags in memory have two interpretations: the full
    tag interpretation (where the pointer tag is between 1 and `TG-1` and the
    last byte of the granule is ordinary data) and the short tag interpretation
    (where the pointer tag is stored in the granule).

    When HWASAN detects an error near a memory tag between 1 and `TG-1`, it
    will show both the memory tag and the last byte of the granule. Currently,
    it is up to the user to disambiguate the two possibilities.

    Because this functionality obsoletes the right aligned heap feature of
    the HWASAN memory allocator (and because we can no longer easily test
    it), the feature is removed.

    Also update the documentation to cover both short granule tags and
    outlined checks.

    Differential Revision: https://reviews.llvm.org/D63908 (detail)
    by pcc
  4. [libFuzzer] Include FuzzedDataProvider.h in the test without "utils" subdir.

    Summary:
    This way the test would better match the intended usage of the header,
    plus it makes some additional testing (e.g. in CI) a bit easier to set up.

    Reviewers: morehouse

    Reviewed By: morehouse

    Subscribers: mgorny, delcypher, #sanitizers, llvm-commits

    Tags: #llvm, #sanitizers

    Differential Revision: https://reviews.llvm.org/D64440 (detail)
    by dor1s
  5. Revert "[TSan] Improve handling of stack pointer mangling in {set,long}jmp, pt.8"

    This reverts commit 521f77e6351fd921f5a81027c7c72addca378989. (detail)
    by yln
Revision: 364448
Changes
  1. build: use multiple `install` rather than building up a list

    Rather than building up a list to iterate over later, just create multiple
    install commands based on the configuration. This makes it easier to see what
    is getting installed and allows for the install handling to be centralised. NFC (detail)
    by Saleem Abdulrasool

Started by upstream project relay-test-suite-verify-machineinstrs build number 5591
originally caused by:

This run spent:

  • 7.2 sec waiting;
  • 30 min build duration;
  • 30 min total from scheduled to completion.