| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 361062
|
| |
|
|
|
|
|
|
| |
It fails to build on some bots.
Also revert follow-up r361055.
llvm-svn: 361059
|
| |
|
|
| |
llvm-svn: 361055
|
| |
|
|
| |
llvm-svn: 361053
|
| |
|
|
| |
llvm-svn: 360829
|
| |
|
|
| |
llvm-svn: 360766
|
| |
|
|
| |
llvm-svn: 360764
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D61819
llvm-svn: 360647
|
| |
|
|
| |
llvm-svn: 360645
|
| |
|
|
| |
llvm-svn: 360644
|
| |
|
|
| |
llvm-svn: 360629
|
| |
|
|
|
|
|
|
| |
This part was accidentally missing from NSA image support commit.
Differential Revision: https://reviews.llvm.org/D61868
llvm-svn: 360623
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
zlib/nozlib, asan/not_asan, msan/not_msan, ubsan/not_ubsan.
We still have two other ways to express the absence of a feature.
First, we have the '!' operator to invert the sense of a keyword. For
example, given a feature that depends on zlib being unavailable, its
test can say:
REQUIRES: !zlib
Second, if a test doesn't play well with some features, such as
sanitizers, that test can say:
UNSUPPORTED: asan, msan
The different ways of writing these exclusions both have the same
technical effect, but have different implications to the reader.
llvm-svn: 360603
|
| |
|
|
|
|
|
|
|
|
|
| |
The tablegen groups only need public_deps for inc files included
(possibly transitively) in other targets. Move inc files that are
internan to the MCTargetDesc libraries into regular deps.
Related to the changes that merged InstPrinter into MCTargetDesc
(360484, 360486 etc).
llvm-svn: 360600
|
| |
|
|
| |
llvm-svn: 360597
|
| |
|
|
| |
llvm-svn: 360553
|
| |
|
|
| |
llvm-svn: 360551
|
| |
|
|
| |
llvm-svn: 360549
|
| |
|
|
|
|
|
|
|
|
| |
Allow using Debian's opt-8, opt-9 with update_test_checks.py
Patch by Shawn Landden!
Differential Revision: https://reviews.llvm.org/D61148
llvm-svn: 360536
|
| |
|
|
| |
llvm-svn: 360508
|
| |
|
|
| |
llvm-svn: 360507
|
| |
|
|
| |
llvm-svn: 360492
|
| |
|
|
| |
llvm-svn: 360491
|
| |
|
|
| |
llvm-svn: 360489
|
| |
|
|
|
|
| |
does not cover all cases either and the case it doesn't cover affects one of the buildbots.
llvm-svn: 360373
|
| |
|
|
|
|
| |
UNSUPPORTED: windows. nowindows is not currently defined and windows does not cover all cases. system-windows is also consistent with how other platforms are used.
llvm-svn: 360368
|
| |
|
|
|
|
| |
It was disabled incorrectly, which meant it wasn't running anywhere.
llvm-svn: 360356
|
| |
|
|
| |
llvm-svn: 360343
|
| |
|
|
|
|
| |
Apple clang is the canonical way to refer to the compiler shipped with Xcode.
llvm-svn: 360307
|
| |
|
|
| |
llvm-svn: 360253
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit appears to be breaking stage-2 builds on GreenDragon. The
OpenMP wrappers for cmath and math.h are copied into the root of the
resource directory and cause a cyclic dependency in module 'Darwin':
Darwin -> std -> Darwin. This blows up when CMake is testing for modules
support and breaks all stage 2 module builds, including the ThinLTO bot
and all LLDB bots.
CMake Error at cmake/modules/HandleLLVMOptions.cmake:497 (message):
LLVM_ENABLE_MODULES is not supported by this compiler
llvm-svn: 360192
|
| |
|
|
| |
llvm-svn: 360141
|
| |
|
|
| |
llvm-svn: 360140
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This reverts commit r360106.
The revisioin causes llvm-tblgen to hang while generating info for
RISCV.td. The root cause might be in the RISCV.td definition but I don't
know enough about this to investigate further.
Command that starts hangning after r360106:
`llvm-build/bin/llvm-tblgen -I llvm/include -I llvm/tools/clang/include -I llvm/lib/Target/RISCV -gen-instr-info llvm/lib/Target/RISCV/RISCV.td`
Reviewers: sammccall, yan_luo, craig.topper, gribozavr
Reviewed By: gribozavr
Subscribers: PkmX, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61632
llvm-svn: 360136
|
| |
|
|
|
|
|
|
| |
Check "Big" instead of "Small" in the second condition.
Differential Revision: https://reviews.llvm.org/D61605
llvm-svn: 360106
|
| |
|
|
| |
llvm-svn: 360074
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D61468
llvm-svn: 360057
|
| |
|
|
|
|
|
|
| |
are done
Differential Revision: https://reviews.llvm.org/D61468
llvm-svn: 360056
|
| |
|
|
| |
llvm-svn: 360049
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
defining them
When builing the hermetic static library, the compiler switch
-fvisibility-global-new-delete-hidden is necessary to get the new and
delete operator definitions made correctly. However, when those
definitions are not included in the library, then this switch does harm.
With lld (though not all linkers) setting STV_HIDDEN on SHN_UNDEF
symbols makes it an error to leave them undefined or defined via dynamic
linking that should generate PLTs for -shared linking (lld makes this a
hard error even without -z defs). Though leaving the symbols undefined
would usually work in practice if the linker were to allow it (and the
user didn't pass -z defs), this actually indicates a real problem that
could bite some target configurations more subtly at runtime. For
example, x86-32 ELF -fpic code generation uses hidden visibility on
declarations in the caller's scope as a signal that the call will never
be resolved to a PLT entry and so doesn't have to meet the special ABI
requirements for PLT calls (setting %ebx). Since these functions might
actually be resolved to PLT entries at link time (we don't know what the
user is linking in when the hermetic library doesn't provide all the
symbols itself), it's not safe for the compiler to treat their
declarations at call sites as having hidden visibility.
Differential Revision: https://reviews.llvm.org/D61572
llvm-svn: 360004
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When builing the hermetic static library, the compiler switch
-fvisibility-global-new-delete-hidden is necessary to get the new and
delete operator definitions made correctly. However, when those
definitions are not included in the library, then this switch does harm.
With lld (though not all linkers) setting STV_HIDDEN on SHN_UNDEF
symbols makes it an error to leave them undefined or defined via dynamic
linking that should generate PLTs for -shared linking (lld makes this a
hard error even without -z defs). Though leaving the symbols undefined
would usually work in practice if the linker were to allow it (and the
user didn't pass -z defs), this actually indicates a real problem that
could bite some target configurations more subtly at runtime. For
example, x86-32 ELF -fpic code generation uses hidden visibility on
declarations in the caller's scope as a signal that the call will never
be resolved to a PLT entry and so doesn't have to meet the special ABI
requirements for PLT calls (setting %ebx). Since these functions might
actually be resolved to PLT entries at link time (we don't know what the
user is linking in when the hermetic library doesn't provide all the
symbols itself), it's not safe for the compiler to treat their
declarations at call sites as having hidden visibility.
Differential Revision: https://reviews.llvm.org/D61571
llvm-svn: 360003
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rev-parse --git-common-dir.
Not all versions of git support git rev-parse --git-common-dir. Rather than erorr or print any kind of
useful error, they just print back '--git-common-dir' instead of a directory. The git-llvm script
ends up taking this '--git-common-dir' as a diretory name to use.
Not sure exactly what happens after that, but the end result is that the 'git llvm push' ends up
looking like it pushed your commits, but really did nothing.
This patch makes the script detect the bogus directory name for --git-common-dir and falls back to using --git-dir instead.
llvm-svn: 359939
|
| |
|
|
| |
llvm-svn: 359888
|
| |
|
|
|
|
|
|
| |
This was omitted in r359805.
Differential Revision: https://reviews.llvm.org/D61462
llvm-svn: 359828
|
| |
|
|
|
|
| |
This reflects changes made in r359763.
llvm-svn: 359825
|
| |
|
|
|
|
| |
This was omitted in r359806 but is already referenced in the GN build.
llvm-svn: 359815
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This change introduces support for building libc++. The library
build should be complete, but not all CMake options have been
replicated in GN. We also don't support tests yet.
We only support two stage build at the moment.
Differential Revision: https://reviews.llvm.org/D61143
llvm-svn: 359806
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This change introduces support for building libcxxabi. The library
build should be complete, but not all CMake options have been
replicated in GN. We also don't support tests yet.
We only support two stage build at the moment.
Differential Revision: https://reviews.llvm.org/D60372
llvm-svn: 359805
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This change introduces support for building libuwind. The library
build should be complete, but not all CMake options have been
replicated in GN. We also don't support tests yet.
We only support two stage build at the moment.
Differential Revision: https://reviews.llvm.org/D60370
llvm-svn: 359804
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The Tooling tests do have a lit.local.cfg with
if not config.root.clang_staticanalyzer:
config.unsupported = True
so what's wrong isn't the missing dep, but that lit prints a warning for
the binary missing. This will need a different kind of fix.
llvm-svn: 359739
|