Started 4 mo 4 days ago
Took 1 hr 13 min on green-dragon-23

Success Build #2951 (Aug 5, 2019 7:20:21 AM)

Revisions
  • http://llvm.org/svn/llvm-project/llvm/trunk : 367867
  • http://llvm.org/svn/llvm-project/cfe/trunk : 367866
  • http://llvm.org/svn/llvm-project/lldb/trunk : 367867
  • http://llvm.org/svn/llvm-project/debuginfo-tests/trunk : 364589
  • http://llvm.org/svn/llvm-project/libcxx/trunk : 367777
Changes
  1. Changing representation of .cv_def_range directives in Codeview debug info assembly format for better readability (detail)
    by nilanjana_basu
  2. [Driver] Properly use values-X[ca].o, values-xpg[46].o on Solaris

    Builtins-*-sunos :: compiler_rt_logbf_test.c currently FAILs on Solaris, both SPARC and
    x86, 32 and 64-bit.

    It turned out that this is due to different behaviour of logb depending on the C
    standard compiled for, as documented on logb(3M):

      RETURN VALUES
             Upon successful completion, these functions return the exponent of x.
     
             If x is subnormal:
     
                 o      For SUSv3-conforming applications compiled with the c99 com-
                        piler  driver  (see standards(7)), the exponent of x as if x
                        were normalized is returned.
     
                 o      Otherwise, if compiled with the cc compiler  driver,  -1022,
                        -126,  and  -16382  are  returned  for  logb(), logbf(), and
                        logbl(), respectively.

    Studio c99 and gcc control this by linking with the appropriate version of values-xpg[46].o, but clang uses neither of those.

    The following patch fixes this by following what gcc does, as corrected some time ago in

      Fix use of Solaris values-Xc.o (PR target/40411)
      https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02350.html and
      https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02384.html.

    Tested on x86_64-pc-solaris2.11, sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu.

    Differential Revision: https://reviews.llvm.org/D64793 (detail)
    by ro
  3. [lldb][clang] Reflect LangStandard.h move to clang/Basic

    D65562 <https://reviews.llvm.org/D65562> moves LangStandard.h from clang/Frontend to clang/Basic.  This patch
    adjusts the single file in lldb that uses it to match.

    Tested on x86_64-pc-linux-gnu.

    Differential Revision: https://reviews.llvm.org/D65717 (detail)
    by ro
  4. Move LangStandard*, InputKind::Language to Basic

    This patch is a prerequisite for using LangStandard from Driver in
    https://reviews.llvm.org/D64793.

    It moves LangStandard* and InputKind::Language to Basic.  It is mostly
    mechanical, with only a few changes of note:

    - enum Language has been changed into enum class Language : uint8_t to
      avoid a clash between OpenCL in enum Language and OpenCL in enum
      LangFeatures and not to increase the size of class InputKind.

    - Now that getLangStandardForName, which is currently unused, also checks
      both canonical and alias names, I've introduced a helper getLangKind
      which factors out a code pattern already used 3 times.

    The patch has been tested on x86_64-pc-solaris2.11, sparcv9-sun-solaris2.11,
    and x86_64-pc-linux-gnu.

    There's a companion patch for lldb which uses LangStandard.h
    (https://reviews.llvm.org/D65717).

    While polly includes isl which in turn uses InputKind::C, that part of the
    code isn't even built inside the llvm tree.  I've posted a patch to allow
    for both InputKind::C and Language::C upstream
    (https://groups.google.com/forum/#!topic/isl-development/6oEvNWOSQFE).

    Differential Revision: https://reviews.llvm.org/D65562 (detail)
    by ro
  5. [yaml2obj][tests] Fix overly restrictive od output check

    Summary:
    rL364517 introduced further instances of `od` output checking of the
    kind previously corrected by rL363829. This patch corrects the issue by
    suppressing output of the input offset. The check remains sufficiently
    sensitive to test for the intended value of the specific byte since the
    relevant byte value is the only output we are expecting from `od`.

    Reviewers: grimar, xingxue, daltenty, jasonliu, jhenderson, MaskRay

    Reviewed By: grimar, MaskRay

    Subscribers: llvm-commits

    Tags: #llvm

    Differential Revision: https://reviews.llvm.org/D65680 (detail)
    by hubert.reinterpretcast
  6. Revert "Changing representation of .cv_def_range directives in Codeview debug info assembly format for better readability"

    This reverts commit a885afa9fa8cab3b34f1ddf3d21535f88b662881. (detail)
    by nilanjana_basu
  7. [yaml2obj] - Allow overriding sh_entsize for SHT_GNU_versym sections.

    This allows to write a test case for one of untested errors
    in llvm/Object/ELF.h.

    I did it in this patch to demonstrate.

    Differential revision: https://reviews.llvm.org/D65394 (detail)
    by grimar
  8. [AArch64] Implement initial SVE calling convention support

    Summary:

    This patch adds initial support for the SVE calling convention such that
    SVE types can be passed as arguments and return values to/from a
    subroutine.

    The SVE AAPCS states [1]:

        z0-z7 are used to pass scalable vector arguments to a subroutine,
        and to return scalable vector results from a function. If a
        subroutine takes arguments in scalable vector or predicate
        registers, or if it is a function that returns results in such
        registers, it must ensure that the entire contents of z8-z23 are
        preserved across the call. In other cases it need only preserve the
        low 64 bits of z8-z15, as described in §5.1.2.

        p0-p3 are used to pass scalable predicate arguments to a subroutine
        and to return scalable predicate results from a function. If a
        subroutine takes arguments in scalable vector or predicate
        registers, or if it is a function that returns results in these
        registers, it must ensure that p4-p15 are preserved across the call.
        In other cases it need not preserve any scalable predicate register
        contents.

    SVE predicate and data registers are passed indirectly (i.e. spilled to the
    stack and pass the address) if they exceed the registers used for argument
    passing defined by the PCS referenced above.  Until SVE stack support is merged
    we can't spill SVE registers to the stack, so currently an llvm_unreachable is
    used where we will eventually handle this.

    [1] https://static.docs.arm.com/100986/0000/100986_0000.pdf

    Reviewed By: ostannard

    Differential Revision: https://reviews.llvm.org/D65448 (detail)
    by c-rhodes
  9. [lldb][NFC] Fix documentation for ClangPersistentVariables::m_next_persistent_variable_id (detail)
    by Raphael Isemann
  10. [MCA][doc] Add a section for the 'Bottleneck Analysis'.

    Also clarify the meaning of 'Block RThroughput' and 'RThroughput'. (detail)
    by adibiagio
  11. [obj2yaml] - Teach tool to dump SHT_NULL sections.

    Recently an advanced support of SHT_NULL sections
    was implemented in yaml2obj.

    This patch adds a corresponding support to obj2yaml.

    Differential revision: https://reviews.llvm.org/D65215 (detail)
    by grimar
  12. Changing representation of .cv_def_range directives in Codeview debug info assembly format for better readability (detail)
    by nilanjana_basu
  13. test-release.sh: Perform the sed substitution on both files (PR42739)

    The comparison would otherwise fail if Phase2 occurrs naturally in the
    object file. It would get replaced with Phase3 in the one .o, but not
    in the other.

    We were already running both files through sed to have them processed in
    this same way; this is a logical extension of that. (detail)
    by hans
  14. Write the RequiredLibraries for 'all' in LibraryDependencies.inc in a deterministic order (PR42739) (detail)
    by hans
  15. gn build: Merge r367839 (detail)
    by nico
  16. [lldb][NFC] Clang format GetNextPersistentVariableName signature (detail)
    by Raphael Isemann
  17. [lldb] Move redundant persistent variable counter to ClangPersistentVariables

    Currently Target::m_next_persistent_variable_index is counting up
    for our persistent variables ($0, $1, ...) but we also have a
    unused counter that is supposed to do this in
    ClangPersistentVariables but that stays always at 0 (because
    we currently increase the target counter when we should increase
    that unused counter).

    This patch removes the counter in Target and lets the documented
    counter in ClangPersistentVariables do the variable counting.

    Patch *should* be NFC, but it might unexpectedly bring LLDB to
    new code paths that could contain exciting new bugs to fix. (detail)
    by Raphael Isemann
  18. [clang][NFC] Remove unused private variable 'CI' in CrossTranslationUnit.h

    It seems because of the recent refactorings this variable has become unused
    and now we get this warning in the build logs:

    In file included from llvm/clang/lib/CrossTU/CrossTranslationUnit.cpp:12:
    llvm/clang/include/clang/CrossTU/CrossTranslationUnit.h:200:21: warning: private field 'CI' is not used [-Wunused-private-field]
      CompilerInstance &CI;
                        ^

    I'll remove them for now to get the builds back to green. (detail)
    by Raphael Isemann
  19. [AST] Fix RecursiveASTVisitor visiting implicit constructor initializers.

    Summary: RecursiveASTVisitor was visiting implcit constructor initializers. This caused semantic highlighting in clangd to emit error logs. Fixes this by checking if the constructor is written or if the visitor should visit implicit decls.

    Reviewers: hokein, ilya-biryukov

    Subscribers: kadircet, cfe-commits

    Tags: #clang

    Differential Revision: https://reviews.llvm.org/D65735 (detail)
    by jvikstrom

Started by upstream project lldb-cmake build number 32696
originally caused by:

  • Started by timer
  • Started by timer

Started by upstream project lldb-cmake build number 32697
originally caused by:

  • Started by timer

Started by upstream project lldb-cmake build number 32698
originally caused by:

  • Started by timer

Started by upstream project lldb-cmake build number 32699
originally caused by:

  • Started by timer

Started by upstream project lldb-cmake build number 32700
originally caused by:

  • Started by timer

Started by upstream project lldb-cmake build number 32701
originally caused by:

  • Started by timer

Started by upstream project lldb-cmake build number 32702
originally caused by:

  • Started by timer

This run spent:

  • 2 hr 9 min waiting;
  • 1 hr 13 min build duration;
  • 3 hr 22 min total from scheduled to completion.
Test Result (no failures)