Rather than converting to the legacy 106-bit format, perform next() on the
low APFloat. Of course, we need to renormalize the two APFloats if
either of the two constraints are violated:
1. abs(low) <= ulp(high)/2
2. high = rtne(high + low)
Should renormalization be needed, it will increment the high component
and set low to the smallest value which obeys these rules.
The declarations for this API are missing in older mingw-w64 headers
(versions before v12). This API is also hidden if building with MS
WinSDK if targeting versions before Windows 10.
Check whether THREAD_POWER_THROTTLING_CURRENT_VERSION is defined before
using this API; this constant is a #define in both WinSDK and mingw-w64.
These changes allow LLVM and Clang to be built with Clang targeting
Arm64EC using the MSVC linker.
Built with these options:
```
-DLLVM_ENABLE_PROJECTS="clang"
-DLLVM_HOST_TRIPLE=arm64ec-pc-windows-msvc
-DCMAKE_C_COMPILER=clang-cl.exe
-DCMAKE_C_COMPILER_TARGET=arm64ec-pc-windows-msvc
-DCMAKE_CXX_COMPILER=clang-cl.exe
-DCMAKE_CXX_COMPILER_TARGET=arm64ec-pc-windows-msvc
-DCMAKE_LINKER_TYPE=MSVC
```
This switches to `makeIntrusiveRefCnt<FileSystem>` where creating a new
object, and to passing/returning by `IntrusiveRefCntPtr<FileSystem>`
instead of `FileSystem*` or `FileSystem&`, when dealing with existing
objects.
Part of cleanup #151026.
The SetThreadInformation API allows threads to be scheduled on the most
efficient cores on the most efficient frequency.
Using this API for ThreadPriority::Background should make clangd-based
IDEs a little less CPU hungry.
---------
Co-authored-by: Alexandre Ganea <aganea@havenstudios.com>
This allows to set an optional integer level for a given debug type. The
string format is `type[:level]`, and the integer is interpreted as such:
- if not provided: all debugging for this debug type is enabled.
- if >0: all debug that is < to the level is enabled.
- if 0: same as for >0 but also does not disable the other debug-types,
it acts as a negative filter.
The LDBG() macro is updated to accept an optional log level to
illustrate the feature. Here is the expected behavior:
LDBG() << "A"; // Identical to LDBG(1) << "A";
LDBG(2) << "B";
With `--debug-only=some_type`: we'll see A and B in the output.
With `--debug-only=some_type:1`: we'll see A but not B in the output.
With `--debug-only=some_type:2`: we'll see A and B in the output. (same
with any level above 2)
With `--debug-only=some_type:0`: we'll see neither A nor B in the
output, but we'll see any other logging for other debug types.
report_fatal_error is not a good way to report diagnostics to the users, so this switches to using actual diagnostic reporting mechanisms instead.
Fixes#147187
## Purpose
This patch is one in a series of code-mods that annotate LLVM’s public
interface for export. This patch annotates the `llvm:🆑:opt` explicit
template instantiations for export with `LLVM_TEMPLATE_ABI` and
`LLVM_EXPORT_TEMPLATE`. This annotation currently has no meaningful
impact on the LLVM build; however, it is a prerequisite to support an
LLVM Windows DLL (shared library) build.
## Background
This effort is tracked in #109483. Additional context is provided in
[this
discourse](https://discourse.llvm.org/t/psa-annotating-llvm-public-interface/85307),
and documentation for `LLVM_ABI` and related annotations is found in the
LLVM repo
[here](https://github.com/llvm/llvm-project/blob/main/llvm/docs/InterfaceExportAnnotations.rst).
Annotating the `llvm:🆑:opt` template instances for DLL export was not
straight-forward like other explicit template instances that have
already been annotated. Annotating them as documented
[here](https://github.com/llvm/llvm-project/blob/main/llvm/docs/InterfaceExportAnnotations.rst#templates)
results in link errors when building a Windows DLL using MSVC.
## Overview
There are two specific issues that appear when exporting the
`llvm:🆑:opt` templates and compiling a Windows DLL with MSVC:
1. We cannot export `opt<std::string>`. This is because MSVC exports all
ancestor classes when exporting an instantiated template class. Since
one of `opt`'s ancestor classes is its type argument (via
`opt_storage`), it is an ancestor of `std::string`. Therefore, if we
export `opt<std::string>` from the LLVM DLL, MSVC forces
`std::basic_string` to also be exported. This leads to duplicate symbol
errors and generally seems like a bad idea. Compiling with `clang-cl`
does not exhibit this behavior.
2. The `opt` template instances other than `opt<bool>` get optimized out
because they are not referenced in the TU (`opt<bool>` actually is). It
is unclear exactly why MSVC optimizes these template instances away, but
`clang-cl` does not. Adding explicit references to the instantiated
`opt` template classes' vtables via implicit virtual destructor forces
MSVC to export them.
## Validation
Windows with MSVC
Windows with Clang
This patch enables lld to read AArch64 Build Attributes and convert them
into GNU Properties.
Changes:
- Parses AArch64 Build Attributes from input object files.
- Converts known attributes into corresponding GNU Properties.
- Merges attributes when linking multiple objects.
Spec reference:
https://github.com/ARM-software/abi-aa/pull/230/files#r1030
Co-authored-by: Sivan Shani <sivan.shani@arm.com>
---------
Co-authored-by: Sivan Shani <sivan.shani@arm.com>
If the path is longer than sockaddr_un's buffer, it will be truncated,
at which point it may become indistinguishable from similar truncated
paths. This will cause `bind` to fail with an "Address already in use"
error. There is some existing code that checks `fs::exists` to catch
these errors, but since `fs::exists` compares the full un-truncated
paths, a too-long path will prevent those checks from working.
rdar://154397133
Added by #147948, blake3_xof_many and blake3_compress_subtree_wide cause
conflicts when linking llvm and blake3 statically into the same binary.
Similar to #148607.
Most atomic functions used Interlocked functions in case of MSVC (since MSVC does not do C11 yet).
But few load/store functions are dummy.
Use Interlocked functions for these atomics to ensure they are thread-safe.
This PR fixes#146205.
LLVM is on VS 2019 version 16.7 currently and eventually we require VS 2022 if we wanted to use stdatomics in rpmalloc, etc. In the meanwhile, we use the Interlocked intrinsics when building with MSVC.
`g_cpu_features` can be updated multiple times by `get_cpu_features()`,
which reports a thread sanitizer error when used with multiple lld
threads.
This PR updates BLAKE3 to v1.8.2.
This is so that we'll be able to use it in compiler-rt as well.
Dependencies on LLVM Support were removed from the header by restoring
code from the original SipHash implementation.
Reviewers: kuhar, dwblaikie, ahmedbougacha
Reviewed By: dwblaikie
Pull Request: https://github.com/llvm/llvm-project/pull/134197
When an llvm tool crashes (e.g. from a segmentation fault),
SignalHandler will re-raise the signal. The effect is that crash reports
now contain SignalHandler in the stack trace. The crash reports are
still useful, but the presence of SignalHandler can confuse tooling and
automation that deduplicate or analyze crash reports.
rdar://150464802
Calls to the posix `write` function can return -1 and set errno to
`EINTR` or perform partial writes when interrupted by signals. In those
cases applications are supposed to just try again. See for example the
documentation in glibc:
https://sourceware.org/glibc/manual/latest/html_node/I_002fO-Primitives.html#index-write
This fixes the uses in `ErrorHandling.cpp` to retry as needed.
This is motivated by the [SFrame format](https://discourse.llvm.org/t/rfc-adding-sframe-support-to-llvm/86900),
which contains several signed fields.
Having explicit signed operations makes the parsing code read better and
avoids potential surprises if e.g. a "signed" uint8_t value is converted
ta greater width.
PR145731 corrected the analyzer test runner to consider use of z3 when
used by testcases, which exposed problems in test cases PR37855.c and
crashes in z3-crosscheck.c This change fixes those crashes and
re-enables the test cases that were "XFAIL"'d out.
Co-authored-by: einvbri <vince.a.bridgers@ericsson.com>
This patch fixes the following error:
```
llvm/lib/Support/TextEncoding.cpp:274:11: error: cannot initialize a variable of type 'char *' with an rvalue of type 'const char *'
274 | char *Input = InputLength ? const_cast<char *>(Source.data()) : "";
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
This patch is part of a series that adds origin-tracking to the debugify
source location coverage checks, allowing us to report symbolized stack
traces of the point where missing source locations appear.
This patch adds a pair of new functions in `signals.h` that can be used
to collect and symbolize stack traces respectively. This has major
implementation overlap with the existing stack trace
collection/symbolizing methods, but the existing functions are
specialized for dumping a stack trace to stderr when LLVM crashes, while
these new functions are meant to be called repeatedly during the
execution of the program, and therefore we need a separate set of
functions.
Assume that mingw builds are made with mingw-w64 headers.
The old mingw.org distribution isn't even accessible at the moment, and
their project hosting site (osdn.net) seems to have been down for a
couple of years, and their old project hosting (at sourceforge.net)
hasn't been updated since 2018.
mingw-w64 has had the _HEAPOK define since the initial commits in 2007;
unclear when/where it was added for mingw.org headers, but it does seem
to exist there as well (at least in versions from 2011).
This workaround stems from 53fbecce6e8b7d1f024e3dc6df4160fe9a577ff1 from
2004 - it is no longer relevant today.
## Purpose
This patch ensures that the BLAKE3 implementation in the LLVM Support
library exports its public interface with `__declspec(dllexport)` when
building LLVM as a Windows DLL.
## Background
The effort to support building LLVM as a Windows DLL is tracked in
#109483. Additional context is provided in [this
discourse](https://discourse.llvm.org/t/psa-annotating-llvm-public-interface/85307).
## Overview
Replicate [this
logic](https://github.com/llvm/llvm-project/blob/main/llvm/cmake/modules/AddLLVM.cmake#L662-L664)
from `llvm_add_library()` for the `LLVMSupportBlake3` target. Without
this change, the `llvm_blake_` functions will only be annotated with
`__declspec(dllimport)` when building LLVM as a Windows DLL which leads
to inconsistent DLL linkage warnings from MSVC and `clang-cl`.
#143514 broke the `clang-solaris11-sparcv9` bot; from what I can tell
that’s Solaris and according to `SolarisTargetInfo::getOSDefines`, the
macro `__sun__` should be defined on Solaris, so check for that and
don’t try to query the terminal size if it is defined.
Not sure this is the best solution but hopefully it fixes the bot.
On unix systems, we were trying to determine the terminal width using
the `COULMNS` environment variable. Unfortunately, `COLUMNS` is not
exported by all shells and thus not available on some systems.
We were previously using `ioctl()` for this; fall back to doing so if `COLUMNS`
does not exist or does not store a positive integer.
This essentially reverts a3eb3d3d92d037fe3c9deaad87f6fc42fe9ea766 and
parts of https://reviews.llvm.org/D61326.
For more information, see #139499.
Fixes#139499.
This AutoConvert.h header frequently gets mislabeled as an unused
include because it is guarded by MVS internally and every usage is also
guarded. This refactors the change to remove this guard and instead make
these functions a noop on other non-z/OS platforms.
In Unix/DynamicLibrary.inc, it was already known that Cygwin required
use of `RTLD_DEFAULT` as the `Handle` parameter to `DLSym` to search all
modules for a symbol. Unfortunately, RTLD_DEFAULT is defined as NULL, so
the existing checks of the `Process` handle meant `DLSym` would never be
called on Cygwin. Use the existing `&Invalid` sentinel instead of
`nullptr` for the `Process` handle.
This commit resolves a potential issue of working with uninitialized
memory when querying the CPU's affinity. The man page of
`sched_getaffinity` does not guarantee that the memory will be fully
overwritten, so this change should ensure that issues are avoided.
These are identified by misc-include-cleaner. I've filtered out those
that break builds. Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.
The current implementation set a reference to a nullptr, leading to all
kinds of problems. Instead, we can check the various uses to ensure we
don't deref invalid memory, and improve the logic for how contexts are
passed to children, since that was also subtly wrong in some cases.
