Zvfbfmin does not have any scalar operands making this an unnecessary
dependency. The spec was just updated to remove this. See
86d7a74f4b
This fixes a correctness issue where Xsfvfwmaccqqq was incorrectly
depending on Zfbfmin. The SiFive CPUs that support Xsfvfwmaccqqq do not
implement Zfbfmin, but do implement Zvfbfmin based on a previous
understanding that it only requires Zve32f. I've added tests for this
feature to raise the bar for adding dependencies to it in the future.
The patch adds a helper method to iterate over all subcommands to which
an option belongs. Duplicate code is removed and replaced with calls to
this new method.
The RISC-V vector crypto extensions have been ratified. This patch
updates the Clang and LLVM support for these extensions to be
non-experimental, while leaving the C intrinsics as experimental since
the C intrinsics are not yet standardized.
Co-authored-by: Brandon Wu <brandon.wu@sifive.com>
Now we have default abi lp64 for rv64if and ilp32 for rv32if, which is
different with riscv-gnu-toolchain. In
8e9fb09a0c/configure (L3385)
when have f and not d, it prefers lp64f/ilp32f but no soft float. This
patch tries to make their behaviors consistent.
Crash identified internally in lld's use of StringMap in
`compareSections`. Will investigate offline before recommitting.
This reverts commit 67c631d283.
Underlying StringMap API for providing a hash has caused some problems
(observed a crash in lld) - so reverting this until I can figure out/fix
what's going on there.
This reverts commit 52ba075571.
This reverts commit 2e19760230.
```
[136/6185] Building CXX object lib\Support\CMakeFiles\LLVMSupport.dir\raw_ostream.cpp.obj
C:\Work\david.spickett\llvm-project\llvm\lib\Support\raw_ostream.cpp(977,23): warning: missing field 'wHighVersion' initializer [-Wmissing-field-initializers]
977 | WSADATA WsaData = {0};
| ^
```
According to
https://learn.microsoft.com/en-us/windows/win32/api/winsock/ns-winsock-wsadata
this can have any number of fields depending on some ifdefs,
so I've replaced `{0}` with a memset of whatever the size happens to be.
Probably doesn't matter for correctness anyway, but the compiler
won't see it used uninitialised at least.
This originally used the spelling Ws2_32 when added in
a5ffabce98, but was changed to WS2_32
in 042a2e8932 with the intent to
use the canonical spelling from WinSDK, in order to aid cross
compilation from case sensitive file systems with WinSDK.
However, the WinSDK itself is self-inconsistent with respect
to file name cases. Headers refer to each other with many different
casings, so the original, out of the box casing doesn't work
on case sensitive file systems. Import libraries like these
use a variety of casings (some use all lowercase, some use
CamelCase, some all uppercase, and the suffix is either .lib,
.Lib or .LIB).
In order to use the WinSDK on a case sensitive file system, these
case issues has to be worked around somehow. Either by lowercasing
all files (and the #includes within them, and potentially keeping
symlinks with their original casing), or by setting up a Clang
case insensitive VFS overlay. LLVM's llvm/cmake/platforms/WinMsvc.cmake
sets up such a VFS overlay. For the linker, it creates a directory
with lowercase symlinks.
Therefore, the canonical way of handling these casing issues on
case sensitive file systems is to consistently use lowercase. That
is also what MinGW toolchains use.
As an example, the same list of system_libs refers to advapi32,
even if the actual file on disk in WinSDK is AdvAPI32.Lib.
Likewise, other in-tree build systems that picked up this change
for ws2_32 made it all lowercase, in
b07aaf8d3b and
d22dad9f76. This also matches other
existing references to ws2_32 in e.g.
lldb/source/Plugins/Process/Windows/Common/CMakeLists.txt and
lldb/source/Utility/CMakeLists.txt.
The file name is WS2_32.Lib in all the Windows SDK versions I looked at.
You can get away with the incorrect casing on a case-insensitive file
system but it can matter for cross-compilation.
This patch fixed the following compile error caused by #73603.
```
llvm/lib/Support/raw_ostream.cpp: In static member function ‘static llvm::Expected<llvm::ListeningSocket> llvm::ListeningSocket::createUnix(llvm::StringRef, int)’:
llvm/lib/Support/raw_ostream.cpp:1040:10: error: could not convert ‘ListenSocket’ from ‘llvm::ListeningSocket’ to ‘llvm::Expected<llvm::ListeningSocket>’
return ListenSocket;
^~~~~~~~~~~~
```
The patch improves the reporting for the first option in the command
line when it looks like a subcommand name but does not match any
defined.
Before the patch:
```
> prog baz
prog: Unknown command line argument 'baz'. Try: 'prog --help'
```
With the patch:
```
> prog baz
prog: Unknown subcommand 'baz'. Try: 'prog --help'
prog: Did you mean 'bar'?
```
This patch resolves the following errors on z/OS:
error: no member named 'wait4' in the global namespace
error: no member named 'ru_maxrss' in 'rusage'
error: use of undeclared identifier 'strsignal'
error: Cannot get usage times on this platform
error: Cannot get malloc info on this platform
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
Useful for lldb's const string pool, using the hash to determine which
string map to lock and query/insert.
Derived from https://reviews.llvm.org/D122974 by Luboš Luňák
https://reviews.llvm.org/D154014 addes glob support and enables it when
`#!special-case-list-v2` is the first line. This patch makes the glob
support the default (faster than regex after
https://reviews.llvm.org/D156046) and switches to the deprecated regex
support if `#!special-case-list-v1` is the first line.
I have surveyed many ignore lists. All ignore lists I find only use
basic `*` `.` and don't use regex metacharacters such as `(` and `)`.
(As neither `src:` nor `fun:` benefits from using regex.)
They are unaffected by the transition (with a caution that regex
`src:x/a.pb.*` matches `x/axpbx` but glob `src:x/a.pb.*` doesn't).
There is no deprecating warning. If a user finds
`#!special-case-list-v1`, they shall read that the old syntax is
deprecated.
Link:
https://discourse.llvm.org/t/use-glob-instead-of-regex-for-specialcaselists/71666
This patch renames {starts,ends}with to {starts,ends}_with for
consistency with std::{string,string_view}::{starts,ends}_with in
C++20. Since there are only a handful of occurrences, this patch
skips the deprecation phase and simply renames them.
When a tool defines only one or two subcommands, the `[subcommand]` part
is not displayed in the `USAGE` help line. Note that a similar issue
for printing the list of the subcommands has been fixed in
https://reviews.llvm.org/D25463.
A zero-length StringRef can have a null data pointer, which, if passed to the llvm_regex functions which take a pointer+length, but then convert it into a [begin, end) pointer pair can cause a nullptr+0 expression to be evaluated, which is UB. So avoid that by ensuring the data pointer is always non-null, even in the zero-length case.
Fixed build bot errors.
- Use `StackOption<std::string>` type for the top level option. This
way, a per test-case option is unregistered when destructor of
`StackOption` cleans up state for subsequent test cases.
- Repro the crash with no test sharding `/usr/bin/python3
/path/to/llvm-project/build/./bin/llvm-lit -vv --no-gtest-sharding -j128
/path/to/llvm-project/llvm/test/Unit`. The crash is gone with the fix
(same no-sharding repro)
**Original commit message:**
**Context:**
- In https://lists.llvm.org/pipermail/llvm-dev/2016-June/101804.html and
commit
07670b3e98,
`cl::SubCommand` is introduced.
- Options that don't specify subcommand goes into a special 'top level'
subcommand.
**Motivating Use Case:**
- The motivating use case is to refactor `llvm-profdata` to use
`cl::SubCommand` to organize subcommands. See
https://github.com/llvm/llvm-project/pull/71328. A valid use case that's
not supported before this patch is shown below
```
// show-option{1,2} are associated with 'show' subcommand.
// top-level-option3 is in top-level subcomand (e.g., `profile-isfs` in SampleProfReader.cpp)
llvm-profdata show --show-option1 --show-option2 --top-level-option3
```
- Before this patch, option handler look-up will fail with the following
error message "Unknown command line argument --top-level-option3".
- After this patch, option handler look-up will look up in sub-command
options first, and use top-level subcommand as a fallback, so
'top-level-option3' is parsed correctly.
**Context:**
- In https://lists.llvm.org/pipermail/llvm-dev/2016-June/101804.html and commit 07670b3e98, `cl::SubCommand` is introduced.
- Options that don't specify subcommand goes into a special 'top level' subcommand.
**Motivating Use Case:**
- The motivating use case is to refactor `llvm-profdata` to use `cl::SubCommand` to organize subcommands. See
https://github.com/llvm/llvm-project/pull/71328. A valid use case that's not supported before this patch is shown below
```
// show-option{1,2} are associated with 'show' subcommand.
// top-level-option3 is in top-level subcomand (e.g., `profile-isfs` in SampleProfReader.cpp)
llvm-profdata show --show-option1 --show-option2 --top-level-option3
```
- Before this patch, option handler look-up will fail with the following error message "Unknown command line argument --top-level-option3".
- After this patch, option handler look-up will look up in sub-command options first, and use top-level subcommand as a fallback, so 'top-level-option3' is parsed correctly.
Long scalar values can be split into multiple lines to improve
readability. The rules are described in Section 6.5. "Line Folding",
https://yaml.org/spec/1.2.2/#65-line-folding. In addition, for flow
scalar styles, the Spec states that "All leading and trailing white
space characters on each line are excluded from the content",
https://yaml.org/spec/1.2.2/#73-flow-scalar-styles.
The patch implements these unfolding rules for double-quoted,
single-quoted, and plain scalars.
