glibc annotates `process_vm_readv` with `__THROW`.
lldb/include/lldb/Host/linux/Uio.h and
lldb/source/Host/linux/LibcGlue.cpp don't.
Having a mismatch causes an error with c++17:
../../lldb/source/Host/linux/LibcGlue.cpp:18:9:
error: 'process_vm_readv' is missing exception specification 'throw()'
ssize_t process_vm_readv(::pid_t pid, const struct iovec *local_iov,
^
../../lldb/include/lldb/Host/linux/Uio.h:18:9:
note: previous declaration is here
ssize_t process_vm_readv(::pid_t pid, const struct iovec *local_iov,
^
The diagnostic is a bit misleading, since the previous declaration
in the sysroot (in usr/include/x76_64-linux-gnu/bits/uio-ext.h) is
what has the `__THROW`.
In the cmake build, cmake sets `HAVE_PROCESS_VM_READV` correctly based
on header probing.
In the GN build, just set it to 1 unconditionally on linux. If that
turns out to not be good enough everywhere, we'll have to add a GN arg
for this.
(I'm also setting it to 1 on Android. I'm not sure if that's correct --
but we don't build lldb for Android anyways.)
std::iterator has been deprecated in C++17 and some standard library implementations such as MS STL or libc++ emit deperecation messages when using the class.
Since LLVM has now switched to C++17 these will emit warnings on these implementations, or worse, errors in build configurations using -Werror.
This patch fixes these issues by replacing them with LLVMs own llvm::iterator_facade_base which offers a superset of functionality of std::iterator.
Differential Revision: https://reviews.llvm.org/D131320
This has previously been done for `mlir-opt` and `mlir-reduce` and roughly the same approach has been done here.
The use case for having a separate library is that it is easier for downstream to make custom TableGen backends/executable that work on top of the utilities that are defined in `mlir/TableGen`.
The customization point here is the same one as for any upstream TableGen backends: One can add a new generator by simply creating a global instance of `mlir::GenRegistration`.
Differential Revision: https://reviews.llvm.org/D131112
Also make the soft toolchain requirements hard. This allows
us to use C++17 features in LLVM now.
If we find patterns with C++17 that improve readability
it should be recommended in the coding standards.
Reviewed By: jhenderson, cor3ntin, MaskRay
Differential Revision: https://reviews.llvm.org/D130689
In the case of static compilation the file system is pretty much read-only
and taking a snapshot of it usually is sufficient. In the interactive C++
case the compilation is longer and people can create and include files, etc.
In that case we often do not want to open files or cache failures unless is
absolutely necessary.
This patch extends the original API call by forwarding some optional flags,
so we can continue use it in the previous way with no breakage.
Signed-off-by: Jun Zhang <jun@junz.org>
Differential Revision: https://reviews.llvm.org/D131241
D74537 introduced a bug: if `(config->andFeatures & GNU_PROPERTY_AARCH64_FEATURE_1_PAC) != 0`
with -z pac-plt unspecified, we incorrectly use AArch64BtiPac, whose writePlt will make
out-of-bounds write after the .plt section. This is often benign because the
output section after .plt will usually overwrite the content.
This is very difficult to test without D131247 (Parallelize writes of different OutputSections).
Some tests (e.g. aarch64-feature-pac.s) segfault in libstdc++ _GLIBCXX_DEBUG
builds (enabled by LLVM_ENABLE_EXPENSIVE_CHECKS).
dyn_cast<ThunkSection> is incorrectly true for any SyntheticSection. std::merge
transitively calls mergeCmp(x, x) (due to __glibcxx_requires_irreflexive_pred)
and will segfault in `ta->getTargetInputSection()`. The dyn_cast<ThunkSection>
issue should be eventually fixed properly, bug `a != b` is robust enough for now.
When not set output, set default output to stdout.
When set output with -Fo and no -fcgl, set -emit-obj to generate dx container.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D130858
When performing device only compilation, there was an issue where
`cubin` outputs were being renamed to `cubin` despite the user's name.
This is required in a normal compilation flow as the Nvidia tools only
understand specific filenames instead of checking magic bytes for some
unknown reason. We do not want to perform this transformation when the
user is performing device only compilation.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D131278
Use of `ORIGINAL_PCH_DIR` record has been superseeded by making PCH/PCM files with relocatable paths at write time.
Removing this record is useful for producing an output-path-independent PCH file and enable sharing of the same PCH file even
when it was intended for a different output path.
Differential Revision: https://reviews.llvm.org/D131124
D91426 makes .got possibly empty while needed. If .got and .data have the same
address, and .got's content is written after .data, the first word of .data will
be corrupted.
The bug is not testable without D131247.
The newly-completed papers:
- P0896R4 ("The One Ranges Proposal");
- P1243R4 ("Rangify New Algorithms");
- P1252R2 ("Ranges Design Cleanup");
- P1716R3 ("Range Comparison Algorithms Are Over-Constrained");
- P1871R1 ("Concept traits should be named after concepts");
- P2106R0 ("Alternative wording for GB315 and GB316").
Differential Revision: https://reviews.llvm.org/D131234
This function heap-allocates a ThreadSafeModule (the current C bindings assume
that TSMs are always heap-allocated), but was failing to free it.
Should fix http://llvm.org/PR56953.
Based on `spv.ISubBorrow` from D127909.
Also resolved some clang-tidy warnings.
Reviewed By: antiagainst, ThomasRaoux
Differential Revision: https://reviews.llvm.org/D131281
This function could be called wih access_info & 0x20 or with
flags()->halt_on_error, in which case HandleTagMismatch returns (is not
fatal).
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D131279
This change removes dependency on pgmath mod, and also allows
Fortran runtime to issue a diagnostic message in case of zero
denominator.
Differential Revision: https://reviews.llvm.org/D131192
If we're adding a constant that can't use addi we try a few tricks,
one of which is using li+sh3add. We should not do this if lui+add
would work. For example adding 8192. Using sh3add prevents folding
a sext.w to form addw, thus increasing instruction count.
When setting CMAKE_CXX_STANDARD to 17 and targeting a macOS version
under 10.12 the ifdefs would try to use std::shared_mutex because
the of the C++ standard. This should also check the targeted SDK.
See discussion in: https://reviews.llvm.org/D130689
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D131063
Aarush Bhat