This fixes:
```
[5804/7029] Building CXX object tools\clang\unittests\CMakeFiles\AllClangUnitTests.dir\Analysis\CFGBackEdgesTest.cpp.obj
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\include\xutility(721): warning C4018: '>': signed/unsigned mismatch
...
C:\git\llvm-project\clang\unittests\Analysis\CFGBackEdgesTest.cpp(170): note: see the first reference to 'testing::internal::PredicateFormatterFromMatcher<testing::internal::SizeIsMatcher<testing::internal::GtMatcher<int>>>::operator ()' in 'clang::analysis::`anonymous-namespace'::CFGBackEdgesTest_WhileWithContinueLoop_Test::TestBody'
```
Resolves#186527.
The issue points out that GPRPair merge logic in the RISCVMoveMerger
pass was being called on a target without `zdinx` or `experimental-P`,
triggering an unreachable in `getGPRPairCopyOpcode`.
This patch fixes this issue by guarding `isEvenRegisterCopy` and
`isOddRegisterCopy` to return false when neither Zdinx nor P is present.
AsmPrinter (clang -c a.c) and AsmParser (clang -c a.s, llvm-mc
-filetype=obj a.s) have different ways to emit .note.GNU-stack section.
913c5b4d1fff removed a redundant initSections call from cc1as, but
that was the only place where NoExecStack was consumed for the
assembler path.
Unify the .note.GNU-stack emission in MCELFStreamer::finishImpl,
making the `initSections` parameter redundant.
Add a -filetype=obj test for Solaris (see
https://reviews.llvm.org/D159179), which doesn't use .note.GNU-stack
`initSections` has 20+ uses. The parameter cleanup will be deferred to a
subsequent change.
Fixes https://github.com/llvm/llvm-project/issues/186004
Extend the bugprone-use-after-move check to recognize user defined
smart-pointer-like types that make guarantees on the state of a
moved-from object, leaving it in a valid and specified state that
matches the standard smart pointer's moved-from state (nullptr), where
it is safe to use but not dereference.
Following the RFC discussion:
* Use `[[clang::annotate]]` to mark the types.
* Use an schema for the `[[clang::annotate]]` annotation and arguments
to help avoid conflicts with other users of the attribute.
* The annotation will identify the tool ("clang-tidy") and the arguments
the plugin ("bugprone-use-after-move"), and the behavior of the type
("null_after_move"). E.g.:
`[[clang::annotate("clang-tidy", "bugprone-use-after-move",
"null_after_move")]]`
RFC:
https://discourse.llvm.org/t/rfc-add-a-class-attribute-clang-null-after-move-for-use-after-move-analysis/89760
As pointed out in #187518 , currently, `__builtin_isnormal` returns
`true` for subnormal half precision floating point numbers on `s390x.
This is because there is a custom lowering defined which lowers an `f16`
`IS_FPCLASS` ISD node by extending the `f16` value to `f32`, and then
using SystemZ's "test data class" instruction to determine whether the
number is subnormal. However, a number that is subnormal in 16 bits of
precision will no longer be subnormal in 32 bits of precision, and so
the test always returns true, i.e. all subnormal numbers are classified
as normal.
This PR addresses this by removing the custom lowering and instead
relying on the generic expansion of `IS_FPCLASS`, which does not have
this error.
Fixes#187518 .
Since befaa35212dbaac39cd76a8dc748e4df7c90a0d9, the CI stably failed for
the generic-no-wide-characters build, because in no-`wchar_t` modes, the
header for `__remove_cv_t` wasn't properly included.
This PR adds the missing include of `<__type_traits/remove_cv.h>`.
As drive-by, `<__cstddef/size_t.h>` and
`<__type_traits/is_constant_evaluated.h>`, which are included by
`<cwchar>`, are also made included by `<string>` to avoid potential
regression as we're using `size_t` and
`__libcpp_is_constant_evaluated()` in `<string>`.
Previously, the implicit warnings from force-bti (or gcs=always) weren't
possible to silence.
The force-ibt/cet-report flags could also be handled the same way, but I
haven't checked with GNU ld how they behave. And there, the force-ibt
flag only produces warnings if the IBT bit is missing, while cet-report
warns if either IBT or SHSTK are missing - but force-ibt probably
shouldn't implicitly start warning for missing SHSTK.
This addresses a discrepancy to GNU ld that was noted in #186173.
Session::tryCreateService will try to create an instance of ServiceT by
forwarding the given arguments to the ServiceT::Create method, which
must return an Expected<std::unique_ptr<ServiceT>>.
This enables one-line construction and registration of Services with
fallible constructors (which are expected to be common).
The new code introduced for `-verify-directives` in PR #179835 enforces
that the order of diagnostics matches the order of the directives.
However, before checking this, it sorts the directives by
SourceLocation. Perhaps non-obviously, all directives which appear
inside a single comment are given the same SourceLocation, pointing to
the beginning of the comment. While these are added in order they appear
in the comment, the non-stable std::sort may non-detministically
misorder them. Switching to stable_sort ensures the correct order is
verified.
This was observed as a random test failure on the checks in
clang/test/CXX/drs/cwg25xx.cpp lines 250 and 264, in some builds of
Clang. Note that those lines end in backslashes, and thus, despite
appearances, the directives on the following lines are also within the
same single comment.
Use (nearly) the same code to align case statements and expression, as
the other alignments do. That way we also fix two things:
- Keep the ColumnLimit intact, without duplicating the calculation.
- Align all the case colons, even for empty cases.
Lay the ground for C++26 `constexpr` math functions:
- Introduce `LIBC_ENABLE_CONSTEXPR` macro switch to specify the desire
of `constexpr`-only code route.
- Introduce `LIBC_HAS_CONSTANT_EVALUATION` to indicate that we are using
`constexpr`-only code in all dependent functions.
- Introduce `LIBC_CONSTEXPR` macro qualifier to aid in altering the
signature of non-`constexpr` functions.
Note that non-`constexpr` qualified functions are caused by the
exploitation of non-`constexpr` compatible utils, resulting in
non-qualified dependent function, but it can be modified to be qualified
using other code routes.
If the function is `constexpr` compatible, then it's prohibited to use
`LIBC_CONSTEXPR` as a function qualifier. We only qualify it with
`constexpr` as usual.
`LIBC_CONSTEXPR` may or may not evaluate to `constexpr` depending on the
environment configurations, thus it's only used to modify the function
signature in constant evaluation context and remove the qualifier if
it's not desired (depending on provided configurations).
Possible side effects:
- Current qualified routes may or may not produce the desired ULP, this
is implementation dependent (function by function basis) and needs
further testing of the chosen code route.
- The shared tests in the current configuration can still compile with
unsupported compiler. I didn't want to raise compilation error with
unsupported compilers now, but we need to push compiler support with
newer versions for this one to work as intended.
Resolves: https://github.com/llvm/llvm-project/issues/174933
The issue goes into a case where fetch_sub(n) is properly optimized but
fetch_add(neg(n)) is not optimized to the same code.
Although the issue is tagged for x86 I assumed this be best handled
outside of the backends so I put this in InstCombine.
The assert condition (function is not split or split
into less than three fragments) is not always true now
that we will emit more local symbols due to #184074.
Make the (1 << HBitWidth) % Divisor == 1 path a special case within
the recently added chunk summing algorithm. This allows us to
share the trailing zero shifting code.
While there make some comment improvements and avoid creating
unnecessary nodes.
Currently, Python-defined operations automatically generate an
`__init__` function to serve as the operation builder. Previously, the
parameters of this `__init__` function followed a fairly complex set of
rules. For example:
* All result fields were moved to the front to align with other op
builders.
* Fields of `Optional` type were automatically moved to the end and
treated as keyword parameters.
* If the types of all result fields could be inferred automatically,
then all result fields were removed from the parameter list.
* Other than that, the parameter order followed the field definition
order.
These rules may seem reasonable, and they have worked well in practice,
but they have one major drawback: users cannot easily tell what the
actual `__init__` parameter list will look like when writing code,
because the rules are simply too complicated. Users can inspect the
signature at runtime via `MyOp.__init__.__signature__`, but this is
clearly poor for the development experience.
After some offline discussion with Rolf, we decided to replace this with
the following rules, which is what this PR implements:
* The parameters of `__init__` now strictly follow the field definition
order.
* By default, all parameters are required. A field becomes a keyword
parameter only if it is declared with `= None`.
* By default, no type inference is performed. A field becomes a keyword
parameter and participates in type inference only if it is declared with
`= infer_type()`.
These new rules give users full control over the `__init__` parameter
list, making it easy to understand the parameter order and explicitly
control optional parameters and type inference. In addition, this makes
it much easier in the future to use `dataclass_transform` so that type
checkers can understand these automatically generated `__init__`
methods, although there are still some issues to resolve at the moment.
NOTE that this is a **breaking change**. Even so, I still believe it is
worth making, mainly for two reasons:
- the current number of users of Python-defined dialects is still quite
limited;
- this change will bring long-term benefits.
Assisted by Copilot.
The TPI and IPI streams didn't include a hash map for the generated
types, because the types never got hashes. A hash map is necessary to
resolve forward references when dumping the PDB (checks for
`TpiStream::supportsTypeLookup` which checks the hash map).
With this PR, the hashes are generated. There's no good test that we do
this for the IPI stream as well, because it doesn't have forward
references.
This replaces LegalVT with HiLoVT and LegalWidth with HBitWidth as
they are the same for all current uses.
Then we rewrite the shifts to operate on LL and LH.
There's a slight regression on RISC-V due to different node creation
order leading to different DAG combine order. I have other refactoring
I'd like to explore then I may try to fix that.
It's useful to know which clang library the python bindings are running.
---------
Co-authored-by: Vlad Serebrennikov <serebrennikov.vladislav@gmail.com>
Referencing libSupportHTTP under LINK_LIBS of add_lldb_library() pulls
in the static archive even in a build configuration with
LLVM_LINK_LLVM_DYLIB=On, where libSupportHTTP is part of libLLVM. This
patch moves it to LINK_COMPONENTS to fix the issue.
This is the same fix as in
036429881f8d3037894042c6268b2a94eac8c950, applied on another
library.
getNaturalTypeAlignment on a reference type returned pointer alignment
instead of pointee alignment. Pass the pointee type with
forPointeeType=true to match traditional codegen's
getNaturalPointeeTypeAlignment behavior. Fix applies to both argument
and return type attribute construction paths.
A previous change (86c4e96) did not preserve qualifiers attached to the
AutoType QualType when the type was deduced.
For an AutoType after `getDeducedType()`, qualifiers from the original
QualType were dropped. Preserve and reapply them to the deduced type.
This allows to lower `memref.load`/`store` operations on
`PhysicalStorageBuffer`-typed resources with the underlying type being a
vector type. This improves support for the `PhysicalStorageBuffer`
capability in pipelines that use the Vector dialect for distribution.
Signed-off-by: Artem Gindinson <gindinson@roofline.ai>
```txt
---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name ---
Status quo: 0.4743 (100.0%) 0.3802 (100.0%) 0.8546 (100.0%) 0.8567 (100.0%) bugprone-suspicious-semicolon
With this change: 0.0103 (100.0%) 0.0027 (100.0%) 0.0130 (100.0%) 0.0133 (100.0%) bugprone-suspicious-semicolon
```
Continuing the trend of registering one `anyOf` matcher being slower
than registering each of its matchers separately (see #178829 for a
previous example).
(This PR also changes the traversal mode, but I only saw a small speedup
from that. Most of it came from registering the matchers separately.)
This check wasn't super expensive to begin with, but the speedup is
still pretty nice.
