Started 1 mo 16 days ago
Took 17 hr on green-dragon-08

Failed Build #5457 (Aug 31, 2019 11:58:29 AM)

Revisions
  • http://llvm.org/svn/llvm-project/llvm/trunk : 370596
  • http://llvm.org/svn/llvm-project/cfe/trunk : 370597
  • http://llvm.org/svn/llvm-project/compiler-rt/trunk : 370390
  • http://llvm.org/svn/llvm-project/debuginfo-tests/trunk : 364589
  • http://llvm.org/svn/llvm-project/libcxx/trunk : 370553
  • http://llvm.org/svn/llvm-project/clang-tools-extra/trunk : 370527
Changes
  1. [clang] Devirtualization for classes with destructors marked as 'final'

    A class with a destructor marked final cannot be derived from, so it should afford the same devirtualization opportunities as marking the entire class final.

    Patch by logan-5 (Logan Smith)
    Reviewed by rsmith

    Differential Revision: https://reviews.llvm.org/D66621 (detail/ViewSVN)
    by xbolva00
  2. [NFC] Fixed -Wdocumentation warning

    /srv/llvm-buildbot-srcatch/llvm-build-dir/clang-x86_64-debian-fast/llvm.src/lib/Target/AMDGPU/AMDGPUGenRegisterBankInfo.def:98:1: warning: not a Doxygen trailing comment [-Wdocumentation]
    1 warning generated. (detail/ViewSVN)
    by xbolva00
  3. [NFC] Fix for rL370594 (detail/ViewSVN)
    by xbolva00
  4. [clang] Warning for non-final classes with final destructors

    Marking a class' destructor final prevents the class from being inherited from. However, it is a subtle and awkward way to express that at best, and unintended at worst. It may also generate worse code (in other compilers) than marking the class itself final. For these reasons, this revision adds a warning for nonfinal classes with final destructors, with a note to suggest marking the class final to silence the warning.

    See https://reviews.llvm.org/D66621 for more background.

    Patch by logan-5 (Logan Smith)

    Differential Revision: https://reviews.llvm.org/D66711 (detail/ViewSVN)
    by xbolva00
  5. [InstCombine] mempcpy(d,s,n) to memcpy(d,s,n) + n

    Summary:
    Back-end currently expands mempcpy, but middle-end should work with memcpy instead of mempcpy to enable more memcpy-optimization.

    GCC backend emits mempcpy, so LLVM backend could form it too, if we know mempcpy libcall is better than memcpy + n.
    https://godbolt.org/z/dOCG96

    Reviewers: efriedma, spatel, craig.topper, RKSimon, jdoerfert

    Reviewed By: efriedma

    Subscribers: hjl.tools, llvm-commits

    Tags: #llvm

    Differential Revision: https://reviews.llvm.org/D65737 (detail/ViewSVN)
    by xbolva00
  6. [X86] EltsFromConsecutiveLoads - Don't confuse elt count with vector element count (PR43170)

    EltsFromConsecutiveLoads was assuming that the number of input elts was the same as the number of elements in the output vector type when creating a zeroing shuffle, causing an assert when subvectors were being combined instead of just scalars. (detail/ViewSVN)
    by rksimon
  7. [X86][AVX512] Regenerate tests with common prefixes (detail/ViewSVN)
    by rksimon
  8. [AArch64][x86] increase value type coverage in tests; NFC
    This goes with D67021. (detail/ViewSVN)
    by spatel
  9. Fix shadow variable warning by making CondCodes names more explicit. NFCI. (detail/ViewSVN)
    by rksimon
  10. Revert [Clang Interpreter] Initial patch for the constexpr interpreter

    This reverts r370584 (git commit afcb3de117265a69d21e5673356e925a454d7d02) (detail/ViewSVN)
    by nand
  11. [DAGCombiner] clean up code in visitShiftByConstant()

    This is not quite NFC because the SDLoc propagation is changed,
    but there are no regression test diffs from that. (detail/ViewSVN)
    by spatel
  12. Fix shadow variable warning. NFCI. (detail/ViewSVN)
    by rksimon
  13. [Clang Interpreter] Initial patch for the constexpr interpreter

    Summary:
    This patch introduces the skeleton of the constexpr interpreter,
    capable of evaluating a simple constexpr functions consisting of
    if statements. The interpreter is described in more detail in the
    RFC. Further patches will add more features.

    Reviewers: Bigcheese, jfb, rsmith

    Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits

    Tags: #clang

    Differential Revision: https://reviews.llvm.org/D64146 (detail/ViewSVN)
    by nand
  14. [X86ISelLowering] combineCMov - cleanup CMOV->LEA codegen. NFCI.

    Only compute the diff once and we don't need the truncation code (assert the bitwidth is correct just to be safe). (detail/ViewSVN)
    by rksimon
  15. [X86ISelLowering] LowerSELECT - remove duplicate value type. NFCI.

    VT of SELECT result and selection ops will be the same. (detail/ViewSVN)
    by rksimon
  16. Fix cppcheck shadow variable and variable scope warnings. NFCI. (detail/ViewSVN)
    by rksimon
  17. [DAGCombiner] Match (add X, X) as (shl X, 1) when detecting rotate.

    Summary: The combiner transforms (shl X, 1) into (add X, X).

    Reviewers: craig.topper, efriedma, RKSimon, lebedev.ri

    Subscribers: llvm-commits

    Tags: #llvm

    Differential Revision: https://reviews.llvm.org/D66882 (detail/ViewSVN)
    by deadalnix
  18. [llvm-objcopy] Simplify alignToAddr with llvm::alignTo (detail/ViewSVN)
    by maskray
  19. [DAGCombiner] Don't create illegal narrow stores

    Narrowing stores when the target doesn't support the narrow version
    forces the target to expand into a load-modify-store sequence, which
    is highly suboptimal. The information narrowing throws away (legality
    of the inverse transform) is hard to re-analyze. If the target doesn't
    support a store of the narrow type, don't narrow even in pre-legalize
    mode.

    No test as this is DAGCombiner and depends on target bits. (detail/ViewSVN)
    by jamesm
  20. [LVI] Extract solveBlockValueExtractValue(); NFC

    Extract this method in preparation for additional extractvalue
    support. (detail/ViewSVN)
    by nikic
  21. [CVP] Add tests for simplified with.overflow + icmp; NFC

    These tests are based on D19867. (detail/ViewSVN)
    by nikic
  22. [CVP] Generate simpler code for elided with.overflow intrinsics

    Use a { iN undef, i1 false } struct as the base, and only insert
    the first operand, instead of using { iN undef, i1 undef } as the
    base and inserting both. This is the same as what we do in InstCombine.

    Differential Revision: https://reviews.llvm.org/D67034 (detail/ViewSVN)
    by nikic
  23. [CodeGen] Refactor DAGTypeLegalizer::ExpandIntRes_MULFIX. NFC

    Restructured the code a little bit in preparation for adding
    UMULFIXSAT. I think it will be easier to understand the code
    if not interleaving the codegen for signed/unsigned/saturated
    cases that much. (detail/ViewSVN)
    by bjope
  24. [LangRef] Update saturating examples for llvm.smul.fix.sat. NFC

    Some saturation examples for llvm.smul.fix.sat were not showing
    the correct result. I've adjusted the operands to make sure that
    we actually trigger overflow in those examples. (detail/ViewSVN)
    by bjope
  25. Fix some errors introduced by rL370563 which were not exposed on my local machine.
    1. zlib::compress accept &size_t but the param is an uint64_t.
    2. Some systems don't have zlib installed. Don't use compression by default. (detail/ViewSVN)
    by wmi
  26. [SampleFDO] Add profile symbol list section to discriminate function being
    cold versus function being newly added.

    This is the second half of https://reviews.llvm.org/D66374.

    Profile symbol list is the collection of function symbols showing up in
    the binary which generates the current profile. It is used to discriminate
    function being cold versus function being newly added. Profile symbol list
    is only added for profile with ExtBinary format.

    During profile use compilation, when profile-sample-accurate is enabled,
    a function without profile will be regarded as cold only when it is
    contained in that list.

    Differential Revision: https://reviews.llvm.org/D66766 (detail/ViewSVN)
    by wmi
  27. Introduce a DirectoryEntryRef that stores both a reference and an
    accessed name to the directory entry

    This commit introduces a parallel API that returns a DirectoryEntryRef
    to the FileManager, similar to the parallel FileEntryRef API. All
    uses will have to be update in follow-up patches. The immediate use of the new API in this
    patch fixes the issue where a file manager was reused in clang-scan-deps,
    but reported an different file path whenever a framework lookup was done through a symlink.

    Differential Revision: https://reviews.llvm.org/D67026 (detail/ViewSVN)
    by arphaman
  28. llvm-dwarfdump: Cache CU low_pc when computing statistics. (detail/ViewSVN)
    by dblaikie
  29. [c++20] Add support for designated direct-list-initialization syntax.

    This completes the implementation of P0329R4. (detail/ViewSVN)
    by rsmith
  30. [WebAssembly] Add SIMD QFMA/QFMS

    Summary:
    Adds clang builtins and LLVM intrinsics for these experimental
    instructions. They are not implemented in engines yet, but that is ok
    because the user must opt into using them by calling the builtins.

    Reviewers: aheejin, dschuff

    Reviewed By: aheejin

    Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, cfe-commits, llvm-commits

    Tags: #clang, #llvm

    Differential Revision: https://reviews.llvm.org/D67020 (detail/ViewSVN)
    by tlively
  31. [c++20] Disallow template argument deduction from a braced-init-list
    containing designators. The C++20 wording doesn't actually say what
    happens in this case, but treating this as a non-deduced context seems
    like the most natural behavior.

    (We might want to consider deducing through array designators as an
    extension in the future, but will need to be careful to deduce the array
    bound properly if we do so. That's not permitted herein.) (detail/ViewSVN)
    by rsmith
  32. Revert "Add gdb pretty printers for a wide variety of libc++ data structures."

    This reverts commit d8c9f2f572fe06a34ccfc28ee9223b64d7d275d3. (detail/ViewSVN)
    by saugustine
  33. Add gdb pretty printers for a wide variety of libc++ data structures.

    Summary: Also add a test suite.

    Reviewers: EricWF

    Subscribers: christof, llvm-commits

    Tags: #llvm

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

    Run a pep8 formatter.

    Run pep8 formatter.

    Convert to PEP8, address other comments from code review. (detail/ViewSVN)
    by saugustine
  34. [lit] Only set DYLD_LIBRARY_PATH for shared builds

    In r370135 I committed a temporary workaround for the sanitized bot to
    not set (DY)LD_LIBRARY_PATH when (DY)LD_INSERT_LIBRARIES was set.
    Setting (DY)LD_LIBRARY_PATH is only necessary for (standalone)
    shared-library builds, so a better solution is to only set the
    environment variable when necessary.

    Differential revision: https://reviews.llvm.org/D67012 (detail/ViewSVN)
    by Jonas Devlieghere
  35. [MemorySSA] Rename all phi entries.

    When renaming Phis incoming values, there may be multiple edges incoming
    from the same block (switch). Rename all. (detail/ViewSVN)
    by asbirlea
  36. [GVN] Verify value equality before doing phi translation for call instruction

    This is an updated version of https://reviews.llvm.org/D66909 to fix PR42605.

    Basically, current phi translatation translates an old value number to an new
    value number for a call instruction based on the literal equality of call
    expression, without verifying there is no clobber in between. This is incorrect.

    To get a finegrain check, use MachineDependence analysis to do the job. However,
    this is still not ideal. Although given a call instruction,
    `MemoryDependenceResults::getCallDependencyFrom` returns identical call
    instructions without clobber in between using MemDepResult with its DepType to
    be `Def`. However, identical is too strict here and we want it to be relaxed a
    little to consider phi-translation -- callee is the same, param operands can be
    different. That means changing the semantic of `MemDepResult::Def` and I don't
    know the potential impact.

    So currently the patch is still conservative to only handle
    MemDepResult::NonFuncLocal, which means the current call has no function local
    clobber. If there is clobber, even if the clobber doesn't stand in between the
    current call and the call with the new value, we won't do phi-translate.

    Differential Revision: https://reviews.llvm.org/D67013 (detail/ViewSVN)
    by wmi
  37. ASTReader: Bypass overridden files when reading PCHs

    If contents of a file that is part of a PCM are overridden when reading
    it, but weren't overridden when the PCM was being built, the ASTReader
    will emit an error.  Now it creates a separate FileEntry for recovery,
    bypassing the overridden content instead of discarding it.  The
    pre-existing testcase clang/test/PCH/remap-file-from-pch.cpp confirms
    that the new recovery method works correctly.

    This resolves a long-standing FIXME to avoid hypothetically invalidating
    another precompiled module that's already using the overridden contents.

    This also removes ContentCache-related API that would be unsafe to use
    across `CompilerInstance`s in an implicit modules build.  This helps to
    unblock us sinking it from SourceManager into FileManager in the future,
    which would allow us to delete `InMemoryModuleCache`.

    https://reviews.llvm.org/D66710 (detail/ViewSVN)
    by Duncan P. N. Exon Smith
  38. [c++20] Implement semantic restrictions for C++20 designated
    initializers.

    This has some interesting interactions with our existing extensions to
    support C99 designated initializers as an extension in C++. Those are
    resolved as follows:

    * We continue to permit the full breadth of C99 designated initializers
       in C++, with the exception that we disallow a partial overwrite of an
       initializer with a non-trivially-destructible type. (Full overwrite
       is OK, because we won't run the first initializer at all.)

    * The C99 extensions are disallowed in SFINAE contexts and during
       overload resolution, where they could change the meaning of valid
       programs.

    * C++20 disallows reordering of initializers. We only check for that for
       the simple cases that the C++20 rules permit (designators of the form
       '.field_name =' and continue to allow reordering in other cases).
       It would be nice to improve this behavior in future.

    * All C99 designated initializer extensions produce a warning by
       default in C++20 mode. People are going to learn the C++ rules based
       on what Clang diagnoses, so it's important we diagnose these properly
       by default.

    * In C++ <= 17, we apply the C++20 rules rather than the C99 rules, and
       so still diagnose C99 extensions as described above. We continue to
       accept designated C++20-compatible initializers in C++ <= 17 silently
       by default (but naturally still reject under -pedantic-errors).

    This is not a complete implementation of P0329R4. In particular, that
    paper introduces new non-C99-compatible syntax { .field { init } }, and
    we do not support that yet.

    This is based on a previous patch by Don Hinton, though I've made
    substantial changes when addressing the above interactions.

    Differential Revision: https://reviews.llvm.org/D59754 (detail/ViewSVN)
    by rsmith
  39. Fix SEH_NoReturn machine verifier error (detail/ViewSVN)
    by rnk
  40. [MC] Avoid crashes from improperly nested or wrong target .seh_handlerdata directives (detail/ViewSVN)
    by rnk
  41. Revert [Clang Interpreter] Initial patch for the constexpr interpreter

    This reverts r370531 (git commit d4c1002e0bbbbab50f6891cdd2f5bd3a8f3a3584) (detail/ViewSVN)
    by nand
  42. [X86] Print register names in .seh_* directives

    Also improve assembler parser register validation for .seh_ directives.
    This requires moving X86-specific seh directive handling into the x86
    backend, which addresses some assembler FIXMEs.

    Differential Revision: https://reviews.llvm.org/D66625 (detail/ViewSVN)
    by rnk
  43. [Clang Interpreter] Initial patch for the constexpr interpreter

    Summary:
    This patch introduces the skeleton of the constexpr interpreter,
    capable of evaluating a simple constexpr functions consisting of
    if statements. The interpreter is described in more detail in the
    RFC. Further patches will add more features.

    Reviewers: Bigcheese, jfb, rsmith

    Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits

    Tags: #clang

    Differential Revision: https://reviews.llvm.org/D64146 (detail/ViewSVN)
    by nand
  44. [x86] add tests for shift-logic-shift; NFC (detail/ViewSVN)
    by spatel
  45. [AArch64] add tests for shift-logic-shift; NFC (detail/ViewSVN)
    by spatel
  46. Make add_new_check.py's insertion of registerCheck<> match the sort order

    Summary:
    Following on from review comments in D65919 about the ordering
    of the registerCheck<> calls. Sort based on the check name which might
    be on the line after the registerCheck<>

    Reviewers: aaron.ballman

    Subscribers: cfe-commits, llvm-commits

    Tags: #clang

    Differential Revision: https://reviews.llvm.org/D66505 (detail/ViewSVN)
    by dsanders
  47. [Windows] Disable TrapUnreachable for Win64, add SEH_NoReturn

    Users have complained llvm.trap produce two ud2 instructions on Win64,
    one for the trap, and one for unreachable. This change fixes that.

    TrapUnreachable was added and enabled for Win64 in r206684 (April 2014)
    to avoid poorly understood issues with the Windows unwinder.

    There seem to be two major things in play:
    - the unwinder
    - C++ EH, _CxxFrameHandler3 & co

    The unwinder disassembles forward from the return address to scan for
    epilogues. Inserting a ud2 had the effect of stopping the unwinder, and
    ensuring that it ran the EH personality function for the current frame.
    However, it's not clear what the unwinder does when the return address
    happens to be the last address of one function and the first address of
    the next function.

    The Visual C++ EH personality, _CxxFrameHandler3, needs to figure out
    what the current EH state number is. It does this by consulting the
    ip2state table, which maps from PC to state number. This seems to go
    wrong when the return address is the last PC of the function or catch
    funclet.

    I'm not sure precisely which system is involved here, but in order to
    address these real or hypothetical problems, I believe it is enough to
    insert int3 after a call site if it would otherwise be the last
    instruction in a function or funclet.  I was able to reproduce some
    similar problems locally by arranging for a noreturn call to appear at
    the end of a catch block immediately before an unrelated function, and I
    confirmed that the problems go away when an extra trailing int3
    instruction is added.

    MSVC inserts int3 after every noreturn function call, but I believe it's
    only necessary to do it if the call would be the last instruction. This
    change inserts a pseudo instruction that expands to int3 if it is in the
    last basic block of a function or funclet. I did what I could to run the
    Microsoft compiler EH tests, and the ones I was able to run showed no
    behavior difference before or after this change.

    Differential Revision: https://reviews.llvm.org/D66980 (detail/ViewSVN)
    by rnk
  48. [IFS][NFC] llvm-ifs: Fixing build bot build break: revert r370517 and r370510. (detail/ViewSVN)
    by zer0
  49. [Thumb2] tighten CHECK lines in test; NFC

    The sequence between the function call and the asm start
    may change without affecting what this test is looking for,
    but we should have a better idea about what that sequence
    looks like. (detail/ViewSVN)
    by spatel
  50. [IFS][NFC] llvm-ifs: Fixing build bot error due to commit conflicts.

    r370510 and r370504

    Again only on gcc. (detail/ViewSVN)
    by zer0
  51. gn build: Merge r370512 (detail/ViewSVN)
    by nico
  52. [X86] Fix mul test cases in avx512-broadcast-unfold.ll to not get canonicalized to fadd. Remove the fsub test cases which were also testing fadd.

    Not sure how to prevent an fsub by constant getting turned into an fadd by negative constant. (detail/ViewSVN)
    by ctopper
  53. [clang-tidy] Add llvm-prefer-register-over-unsigned to clang-tidy

    Summary:
    This clang-tidy check is looking for unsigned integer variables whose initializer
    starts with an implicit cast from llvm::Register and changes the type of the
    variable to llvm::Register (dropping the llvm:: where possible).

    Reviewers: arsenm, bogner

    Subscribers: jholewinski, MatzeB, qcolombet, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, wdng, nhaehnle, mgorny, sbc100, jgravelle-google, kristof.beyls, hiraditya, aheejin, kbarton, fedor.sergeev, javed.absar, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, tpr, PkmX, jocewei, jsji, Petar.Avramovic, asbirlea, Jim, s.egerton, cfe-commits, llvm-commits

    Tags: #clang, #llvm

    Differential Revision: https://reviews.llvm.org/D65919 (detail/ViewSVN)
    by dsanders
  54. [IFS][NFC] llvm-ifs: Fixing build errors for bots using GCC.

    gcc produces the error:

    error: specialization of
    ‘template<class T, class Enable> struct llvm::yaml::ScalarTraits’ in
    different namespace

    For all specializations outside of llvm::yaml. So I added llvm::yaml to these
    specializations to fix the errors on the bots building with gcc (/usr/bin/c++). (detail/ViewSVN)
    by zer0
  55. [DFAPacketizer] Allow namespacing of automata per-itinerary

    The Hexagon itineraries are cunningly crafted such that functional units between
    itineraries do not clash. Because all itineraries are bundled into the same DFA,
    a functional unit index clash would cause an incorrect DFA to be generated.

    A workaround for this is to ensure all itineraries declare the universe of all
    possible functional units, but this isn't ideal for three reasons:
      1) We only have a limited number of FUs we can encode in the packetizer, and
         using the universe causes us to hit the limit without care.
      2) Silent codegen faults are bad, and careful triage of the FU list shouldn't
         be required.
      3) Smooshing all itineraries into the same automaton allows combinations of
         instruction classes that cannot exist, which bloats the table.

    A simple solution is to allow "namespacing" packetizers.

    Differential Revision: https://reviews.llvm.org/D66940 (detail/ViewSVN)
    by jamesm
  56. [X86] Regenerate the test cases added in r370506.

    Something weird happened with the v2i64/v2f64 test cases which
    don't use broadcast. So they should already be hoisted, but
    weren't in the version I submitted in r370506. This fixes that.
    Not sure if something changed or I screwed up. (detail/ViewSVN)
    by ctopper
  57. [X86] Add test caes for opportunities for machine LICM to unfold broadcasted constant pool loads.

    MachineLICM is able to unfold loads to move an invariant load out
    a loop, but X86 infrastructure currently lacks the ability to do
    this when avx512 embedded broadcasting is used.

    This test adds examples for the basic float point operations,
    add, mul, and, or, and xor. (detail/ViewSVN)
    by ctopper
  58. [PowerPC][NFC] Avoid checking non-relevant .cfi instructions

    Summary:
    This is brought up in
    https://reviews.llvm.org/D64662?id=209923#inline-599490

    CFI information are non-relevant to quite some testcases,
    we should get rid of checking them when its unecessary.

    This patch avoid generating cfi info in testcases that are not
    testing prolog/epilog or exception handling.

    Reviewers: kbarton, hfinkel, nemanjai, #powerpc

    Reviewed By: hfinkel

    Subscribers: MaskRay, shchenz, llvm-commits

    Tags: #llvm

    Differential Revision: https://reviews.llvm.org/D67016 (detail/ViewSVN)
    by jsji
  59. Fix compilation warnings. NFC. (detail/ViewSVN)
    by hliao

Started by upstream project Clang Stage 2: cmake, R -g Tsan, using Stage 1 RA build number 18221
originally caused by:

Started by upstream project Clang Stage 2: cmake, R -g Tsan, using Stage 1 RA build number 18222
originally caused by:

Started by upstream project Clang Stage 2: cmake, R -g Tsan, using Stage 1 RA build number 18223
originally caused by:

Started by upstream project Clang Stage 2: cmake, R -g Tsan, using Stage 1 RA build number 18224
originally caused by:

This run spent:

  • 22 hr waiting;
  • 17 hr build duration;
  • 1 day 16 hr total from scheduled to completion.

Identified problems

Missing test results

The test result file Jenkins is looking for does not exist after the build.
Indication 1

Ninja target failed

Below is a link to the first failed ninja target.
Indication 2

Regression test failed

This build failed because a regression test in the test suite FAILed. See the test report for details.
Indication 3

Compile Error

This build failed because of a compile error. Below is a list of all errors in the build log:
Indication 4