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.
On Cygwin, UNIX sockets involve a handshake between connect and accept
to enable SO_PEERCRED/getpeereid handling. This necessitates accept
being called before connect can return, but at least the tests in
llvm/unittests/Support/raw_socket_stream_test do both on the same thread
(first connect and then accept), resulting in a deadlock. Add a call to
both places sockets are created that turns off the handshake (and
SO_PEERCRED/getpeereid support).
References:
* cec8a6680e/winsup/cygwin/fhandler/socket_local.cc (L1462-L1471)
* https://inbox.sourceware.org/cygwin/Z_UERXFI1g-1v3p2@calimero.vinschen.de/T/#u
Apply clang-format to regcomp.c since it's not conformant and leads to
clang-format failures when doing individual changes to this file (for
example in https://github.com/llvm/llvm-project/pull/140758). File
generated by running `clang-format -i regcomp.c`
## Purpose
Reverts the preprocessor guards added to the `dump()` methods in
`llvm/Support/ScaledNumber.h` in #139938 so that the header can be
included when building an external project in debug mode against a
release LLVM build.
## Overview
This is a clean revert of two files modified in #139938. The rest of
that change should not cause similar problems.
## Background
The following new build error was reported on #139938, which was merged
last week:
```
module.cpp:(.text._ZNK4llvm12ScaledNumberImE4dumpEv[_ZNK4llvm12ScaledNumberImE4dumpEv]+0x34): undefined reference to `llvm::ScaledNumberBase::dump(unsigned long, short, int)'
```
See further discussion on #139938.
## Validation
Implemented a simple external LLVM project to reproduce the issue.
Verified the the following link failure is observed on LLVM main
(Windows + Clang) without this change:
```
C:\WINDOWS\system32\cmd.exe /C "cd . && C:\PROGRA~1\LLVM\bin\CLANG_~1.EXE -nostartfiles -nostdlib -O0 -g -Xclang -gcodeview -D_DEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrtd -Xlinker /subsystem:console -fuse-ld=lld-link CMakeFiles/llvm-dump-test.dir/main.cxx.obj -o llvm-dump-test.exe -Xlinker /MANIFEST:EMBED -Xlinker /implib:llvm-dump-test.lib -Xlinker /pdb:llvm-dump-test.pdb -Xlinker /version:0.0 -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 -loldnames && cd ."
lld-link: error: undefined symbol: public: static void __cdecl llvm::ScaledNumberBase::dump(unsigned __int64, short, int)
>>> referenced by S:\llvm\llvm-project\llvm\include\llvm\Support\ScaledNumber.h:614
>>> CMakeFiles/llvm-dump-test.dir/main.cxx.obj:(public: void __cdecl llvm::ScaledNumber<unsigned __int64>::dump(void) const)
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
```
Verified the link issue is resolved after applying this change.
Also, manually included all header files that were modified in #139938
in the test program and verified there are no other link errors.
Added APInt::clearBits(unsigned loBit, unsigned hiBit) that clears bits within a certain range.
Fixes#136550
---------
Co-authored-by: Simon Pilgrim <llvm-dev@redking.me.uk>
This patch fixes the following error in case of LLVM_ENABLE_RPMALLOC=ON
and clang or other non MSVC compiler:
```
CMake Error at cmake/modules/AddLLVM.cmake:644 (add_library):
Target "LLVMSupport" links to item " -INCLUDE:malloc" which has leading or
trailing whitespace. This is now an error according to policy CMP0004.
Call Stack (most recent call first):
cmake/modules/AddLLVM.cmake:944 (llvm_add_library)
cmake/modules/AddLLVM.cmake:917 (add_llvm_library)
lib/Support/CMakeLists.txt:139 (add_llvm_component_library)
```
Note `delayload_flags` is empty before this line is case of non MSVC
compiler.
The behavior is the same with CMake 3.25.3 and 4.0.2.
https://github.com/llvm/llvm-project/pull/134787 unintentionally enabled
`--mmap-output-file` by default under LLD which caused the Windows-only
test `lld\test\ELF\link-open-file.test` to fail. This failure uncovered
what appears to be an inconsistency on Windows between
`createOnDiskBuffer` and `createInMemoryBuffer` with respect to `DELETE`
access for the output file.
The output file created by `createOnDiskBuffer` sets the flag
`OF_Delete` as part of `fs::TempFile::create` while the output file
created by `createInMemoryBuffer` sets `OF_None` under
`InMemoryBuffer::commit`.
The test `lld\test\ELF\link-open-file.test` ensures that if
`FILE_SHARE_DELETE` is _not_ specified for an output file that LLD is
expected to overwrite, LLD should fail. This only happens if: "the file
or device has been opened for delete access" which is only done for
`fs::TempFile::create`.
See
https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilew#FILE_SHARE_DELETE.
Therefore, I propose setting `OF_Delete` for `InMemoryBuffer::commit`'s
call to `openFileForWrite` to stay consistent with
`fs::TempFile::create`.
charN_t represent code units of different UTF encodings. Therefore the
values of 2 different charN_t objects do not represent the same
characters.
In order to avoid comparing apples and oranges, we add new warnings to
warn on:
- Implicit conversions
- Comparisons
- Other cases involving arithmetic conversions
We only produce the warning if we cannot establish the comparison would
be safe through constant evaluation.
The new `-Wimplicit-unicode-conversion` warning is enabled by default.
Note that this PR intentionally doesn;t touches char/wchar_t, but it
would be worth considering also warning on extending the new warnings to
these types (in a follow up)
Additionally most arithmetic operations on charN_t don't really make
sense (ie what does it mean to addition code units), so we could add
warnings for that.
Fixes#138526
## Purpose
Add proper preprocessor guards for all `dump()` methods in the LLVM
support library. This change ensures these methods are not part of the
public ABI for release builds.
## Overview
* Annotates all `dump` methods in Support and ADT source with the
`LLVM_DUMP_METHOD` macro.
* Conditionally includes all `dump` method definitions in Support and
ADT source so they are only present on debug/assert builds and when
`LLVM_ENABLE_DUMP` is explicitly defined.
NOTE: For many of these `dump` methods, the implementation was already
properly guarded but the declaration in the header file was not.
## Background
This PR is a redo of #139804 with some changes to fix clang and unit
test build breaks.
This issue was raised in comments on #136629. I am addressing it as a
separate change since it is independent from the changes being made in
that PR.
According to [this
documentation](https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/Support/Compiler.h#L637),
`dump` methods should be annotated with `LLVM_DUMP_METHOD` and
conditionally included as follows:
```
#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
LLVM_DUMP_METHOD void dump() const;
#endif
```
## Validation
* Local release build succeeds.
* CI
## Purpose
Add proper preprocessor guards for all `dump()` methods in the LLVM
support library. This change ensures these methods are not part of the
public ABI for release builds.
## Overview
* Annotates all `dump` methods in Support and ADT source with the
`LLVM_DUMP_METHOD` macro.
* Conditionally includes all `dump` method definitions in Support and
ADT source so they are only present on debug/assert builds and when
`LLVM_ENABLE_DUMP` is explicitly defined.
NOTE: For many of these `dump` methods, the implementation was already
properly guarded but the declaration in the header file was not.
## Background
This issue was raised in comments on #136629. I am addressing it as a
separate change since it is independent from the changes being made in
that PR.
According to [this
documentation](https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/Support/Compiler.h#L637),
`dump` methods should be annotated with `LLVM_DUMP_METHOD` and
conditionally included as follows:
```
#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
LLVM_DUMP_METHOD void dump() const;
#endif
```
## Validation
* Local release build succeeds.
* CI
## Purpose
This patch is one in a series of code-mods that annotate LLVM’s public
interface for export. This patch annotates the `llvm/Support` library.
These annotations currently have no meaningful impact on the LLVM build;
however, they are 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).
The bulk of these changes were generated automatically using the
[Interface Definition Scanner (IDS)](https://github.com/compnerd/ids)
tool, followed formatting with `git clang-format`.
The following manual adjustments were also applied after running IDS on
Linux:
- Add `#include "llvm/Support/Compiler.h"` to files where it was not
auto-added by IDS due to no pre-existing block of include statements.
- Add `LLVM_ABI` to Windows-only code (auto generated with IDS on
Windows)
- Explicitly make classes non-copyable where needed to due IDS adding
`LLVM_ABI` at the class level
- Add `LLVM_TEMPLATE_ABI` and `LLVM_EXPORT_TEMPLATE` to exported
instantiated templates
- Add `LLVM_ABI_FRIEND` to a small number of `friend` function
declarations
- Add `LLVM_ABI` to a subset of private class methods and fields that
require export
- Add `LLVM_ABI` to a small number of symbols that require export but
are not declared in headers
- Add `LLVM_ABI` functions defined via X-macro
## Validation
Local builds and tests to validate cross-platform compatibility. This
included llvm, clang, and lldb on the following configurations:
- Windows with MSVC
- Windows with Clang
- Linux with GCC
- Linux with Clang
- Darwin with Clang
The expectation of this API is that it only changes the major version of
a preexisting version tuple. However, it was adding 0's, which caused
unintended changes in serialization or printing.
Instead, check for the existence of the non-major parts of the tuple.
