Revision tags: llvmorg-21-init, llvmorg-19.1.7 |
|
#
cfe26358 |
| 11-Jan-2025 |
Timm Baeder <tbaeder@redhat.com> |
Reapply "[clang] Avoid re-evaluating field bitwidth" (#122289)
|
#
59bdea24 |
| 08-Jan-2025 |
Timm Bäder <tbaeder@redhat.com> |
Revert "[clang] Avoid re-evaluating field bitwidth (#117732)"
This reverts commit 81fc3add1e627c23b7270fe2739cdacc09063e54.
This breaks some LLDB tests, e.g. SymbolFile/DWARF/x86/no_unique_address-
Revert "[clang] Avoid re-evaluating field bitwidth (#117732)"
This reverts commit 81fc3add1e627c23b7270fe2739cdacc09063e54.
This breaks some LLDB tests, e.g. SymbolFile/DWARF/x86/no_unique_address-with-bitfields.cpp:
lldb: ../llvm-project/clang/lib/AST/Decl.cpp:4604: unsigned int clang::FieldDecl::getBitWidthValue() const: Assertion `isa<ConstantExpr>(getBitWidth())' failed.
show more ...
|
#
81fc3add |
| 08-Jan-2025 |
Timm Baeder <tbaeder@redhat.com> |
[clang] Avoid re-evaluating field bitwidth (#117732)
Save the bitwidth value as a `ConstantExpr` with the value set. Remove the `ASTContext` parameter from `getBitWidthValue()`, so the latter simply
[clang] Avoid re-evaluating field bitwidth (#117732)
Save the bitwidth value as a `ConstantExpr` with the value set. Remove the `ASTContext` parameter from `getBitWidthValue()`, so the latter simply returns the value from the `ConstantExpr` instead of constant-evaluating the bitwidth expression every time it is called.
show more ...
|
Revision tags: llvmorg-19.1.6, llvmorg-19.1.5 |
|
#
9b2ec87f |
| 29-Nov-2024 |
Balazs Benics <benicsbalazs@gmail.com> |
[analyzer] Avoid creating LazyCompoundVal when possible (#116840)
In #115916 I allowed copying empty structs.
Later in #115917 I changed how objects are copied, and basically when we
would want to
[analyzer] Avoid creating LazyCompoundVal when possible (#116840)
In #115916 I allowed copying empty structs.
Later in #115917 I changed how objects are copied, and basically when we
would want to copy a struct (an LCV) of a single symbol (likely coming
from an opaque fncall or invalidation), just directly bind that symbol
instead of creating an LCV referring to the symbol. This was an
optimization to skip a layer of indirection.
Now, it turns out I should have apply the same logic in #115916. I
should not have just blindly created an LCV by calling
`createLazyBinding()`, but rather check if I can apply the shortcut
described in #115917 and only create the LCV if the shortcut doesn't
apply.
In this patch I check if there is a single default binding that the copy
would refer to and if so, just return that symbol instead of creating an
LCV.
There shouldn't be any observable changes besides that we should have
fewer LCVs. This change may surface bugs in checkers that were
associating some metadata with entities in a wrong way. Notably,
STLAlgorithmModeling and DebugIteratorModeling checkers would likely
stop working after this change.
I didn't investigate them deeply because they were broken even prior to
this patch. Let me know if I should migrate these checkers to be just as
bugged as they were prior to this patch - thus make the tests pass.
show more ...
|
Revision tags: llvmorg-19.1.4 |
|
#
4610e5c7 |
| 14-Nov-2024 |
Balazs Benics <benicsbalazs@gmail.com> |
[analyzer] Don't copy field-by-field conjured LazyCompoundVals (2/4) (#115917)
Split from #114835
|
#
b96c24b8 |
| 14-Nov-2024 |
Balazs Benics <benicsbalazs@gmail.com> |
[analyzer] Allow copying empty structs (1/4) (#115916)
We represent copies of structs by LazyCompoundVals, that is basically a
snapshot of the Store and Region that your copy would refer to.
Thi
[analyzer] Allow copying empty structs (1/4) (#115916)
We represent copies of structs by LazyCompoundVals, that is basically a
snapshot of the Store and Region that your copy would refer to.
This snapshot is actually not taken for empty structs (structs that have
no non-static data members), because the users won't be able to access
any fields anyways, so why bother.
However, when it comes to taint propagation, it would be nice if
instances of empty structs would behave similar to non-empty structs.
For this, we need an identity for which taint can bind, so Unknown -
that was used in the past wouldn't work.
Consequently, copying the value of an empty struct should behave the
same way as a non-empty struct, thus be represented by a
LazyCompoundVal.
Split from #114835
show more ...
|
#
ae7392bf |
| 12-Nov-2024 |
Balazs Benics <benicsbalazs@gmail.com> |
Reapply "[analyzer][NFC] Make RegionStore dumps deterministic" (#115884)
This is reapplies #115615 without using tuples. The eager call of `getRegion()` and `getOffset()` could cause crashes when th
Reapply "[analyzer][NFC] Make RegionStore dumps deterministic" (#115884)
This is reapplies #115615 without using tuples. The eager call of `getRegion()` and `getOffset()` could cause crashes when the Store had symbolic bindings.
Here I'm fixing the crash by lazily calling those getters.
Also, the tuple version poorly sorted the Clusters. The memory spaces should have come before the regular clusters. Now, that is also fixed here, demonstrated by the test.
show more ...
|
#
469520ed |
| 12-Nov-2024 |
Balazs Benics <benicsbalazs@gmail.com> |
Revert "[analyzer][NFC] Make RegionStore dumps deterministic" (#115881)
Reverts llvm/llvm-project#115615
There are two problems with this PR:
1) If any of the dumps contains a store with a symbo
Revert "[analyzer][NFC] Make RegionStore dumps deterministic" (#115881)
Reverts llvm/llvm-project#115615
There are two problems with this PR:
1) If any of the dumps contains a store with a symbolic binding, we
crash.
2) The memory space clusters come last among the clusters, which is not
what I intended.
I'm reverting because of the crash.
show more ...
|
#
e05d91b3 |
| 12-Nov-2024 |
Balazs Benics <benicsbalazs@gmail.com> |
[analyzer][NFC] Make RegionStore dumps deterministic (#115615)
Dump the memory space clusters before the other clusters, in
alphabetical order. Then default bindings over direct bindings, and if
a
[analyzer][NFC] Make RegionStore dumps deterministic (#115615)
Dump the memory space clusters before the other clusters, in
alphabetical order. Then default bindings over direct bindings, and if
any has symbolic offset, then those should come before the ones with
concrete offsets.
In theory, we should either have a symbolic offset OR concrete offsets,
but never both at the same time.
Needed for #114835
show more ...
|
Revision tags: llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1 |
|
#
b1e4656e |
| 24-Sep-2024 |
Pavel Skripkin <paskripkin@gmail.com> |
[NFC][analyzer] Make `invalidateRegions` accept `Stmt` instead of `Expr` (#109792)
As was reported [here](https://github.com/llvm/llvm-project/pull/103714#pullrequestreview-2238037812), `invalidateR
[NFC][analyzer] Make `invalidateRegions` accept `Stmt` instead of `Expr` (#109792)
As was reported [here](https://github.com/llvm/llvm-project/pull/103714#pullrequestreview-2238037812), `invalidateRegions` should accept `Stmt` instead of `Expr`. This conversion is possible, since `Expr` was anyway converted back to `Stmt` later.
This refactoring is needed to fix another FP related to use of inline assembly. The fix would be to change `State->bindLoc` to `state->invalidateRegions` inside inline assembly visitor, since `bindLoc` only binds to offset 0, which is not really correct semantics in case of inline assembly.
show more ...
|
Revision tags: llvmorg-19.1.0 |
|
#
db6051da |
| 09-Sep-2024 |
Pavel Skripkin <paskripkin@gmail.com> |
[analyzer] fix crash on binding to symbolic region with `void *` type (#107572)
As reported in https://github.com/llvm/llvm-project/pull/103714#issuecomment-2295769193. CSA crashes on trying to bind
[analyzer] fix crash on binding to symbolic region with `void *` type (#107572)
As reported in https://github.com/llvm/llvm-project/pull/103714#issuecomment-2295769193. CSA crashes on trying to bind value to symbolic region with `void *`. This happens when such region gets passed as inline asm input and engine tries to bind `UnknownVal` to that region.
Fix it by changing type from void to char before calling `GetElementZeroRegion`
show more ...
|
Revision tags: llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5 |
|
#
7d8616ed |
| 19-Apr-2024 |
Balazs Benics <benicsbalazs@gmail.com> |
[analyzer] Fix stores through label locations (#89265)
Interestingly, this case crashed from the very beginning of the project,
at least starting by clang-3.
As a "fix" I just do the same thing
[analyzer] Fix stores through label locations (#89265)
Interestingly, this case crashed from the very beginning of the project,
at least starting by clang-3.
As a "fix" I just do the same thing as we do for concrete integers. It
might not be the best we could do, but arguably, it's still better than
crashing.
Fixes #89185
show more ...
|
#
3d56ea05 |
| 18-Apr-2024 |
Timm Baeder <tbaeder@redhat.com> |
[clang][NFC] Fix FieldDecl::isUnnamedBitfield() capitalization (#89048)
We always capitalize bitfield as "BitField".
|
Revision tags: llvmorg-18.1.4, llvmorg-18.1.3 |
|
#
28ddbd4a |
| 26-Mar-2024 |
Chris B <chris.bieneman@me.com> |
[NFC] Refactor ConstantArrayType size storage (#85716)
In PR #79382, I need to add a new type that derives from
ConstantArrayType. This means that ConstantArrayType can no longer use
`llvm::Traili
[NFC] Refactor ConstantArrayType size storage (#85716)
In PR #79382, I need to add a new type that derives from
ConstantArrayType. This means that ConstantArrayType can no longer use
`llvm::TrailingObjects` to store the trailing optional Expr*.
This change refactors ConstantArrayType to store a 60-bit integer and
4-bits for the integer size in bytes. This replaces the APInt field
previously in the type but preserves enough information to recreate it
where needed.
To reduce the number of places where the APInt is re-constructed I've
also added some helper methods to the ConstantArrayType to allow some
common use cases that operate on either the stored small integer or the
APInt as appropriate.
Resolves #85124.
show more ...
|
Revision tags: llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init |
|
#
8ee3dfd7 |
| 01-Jan-2024 |
Balazs Benics <benicsbalazs@gmail.com> |
[analyzer][NFC] Take SVal and NonLoc by value
|
Revision tags: llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init |
|
#
5c23e27b |
| 05-Jul-2023 |
Balazs Benics <benicsbalazs@gmail.com> |
[analyzer][NFC] Move away from using raw-for loops inside StaticAnalyzer
I'm involved with the Static Analyzer for the most part. I think we should embrace newer language standard features and gradu
[analyzer][NFC] Move away from using raw-for loops inside StaticAnalyzer
I'm involved with the Static Analyzer for the most part. I think we should embrace newer language standard features and gradually move forward.
Differential Revision: https://reviews.llvm.org/D154325
show more ...
|
Revision tags: llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1 |
|
#
558b46fd |
| 22-Mar-2023 |
Balazs Benics <benicsbalazs@gmail.com> |
[analyzer] Fix crashing getSValFromInitListExpr for nested initlists
In the following example, we will end up hitting the `llvm_unreachable()`: https://godbolt.org/z/5sccc95Ec ```lang=C++ enum class
[analyzer] Fix crashing getSValFromInitListExpr for nested initlists
In the following example, we will end up hitting the `llvm_unreachable()`: https://godbolt.org/z/5sccc95Ec ```lang=C++ enum class E {}; const E glob[] = {{}}; void initlistWithinInitlist() { clang_analyzer_dump(glob[0]); // crashes at loading from `glob[0]` } ```
We should just return `std::nullopt` instead for these cases. It's better than crashing.
Reviewed By: xazax.hun
Differential Revision: https://reviews.llvm.org/D146538
show more ...
|
Revision tags: llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init |
|
#
2d861436 |
| 14-Jan-2023 |
Kazu Hirata <kazu@google.com> |
[clang] Remove remaining uses of llvm::Optional (NFC)
This patch removes several "using" declarations and #include "llvm/ADT/Optional.h".
This is part of an effort to migrate from llvm::Optional to
[clang] Remove remaining uses of llvm::Optional (NFC)
This patch removes several "using" declarations and #include "llvm/ADT/Optional.h".
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
show more ...
|
#
6ad0788c |
| 14-Jan-2023 |
Kazu Hirata <kazu@google.com> |
[clang] Use std::optional instead of llvm::Optional (NFC)
This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to remove #include "llvm/ADT/Optional.h".
This is p
[clang] Use std::optional instead of llvm::Optional (NFC)
This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to remove #include "llvm/ADT/Optional.h".
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
show more ...
|
#
a1580d7b |
| 14-Jan-2023 |
Kazu Hirata <kazu@google.com> |
[clang] Add #include <optional> (NFC)
This patch adds #include <optional> to those files containing llvm::Optional<...> or Optional<...>.
I'll post a separate patch to actually replace llvm::Option
[clang] Add #include <optional> (NFC)
This patch adds #include <optional> to those files containing llvm::Optional<...> or Optional<...>.
I'll post a separate patch to actually replace llvm::Optional with std::optional.
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
show more ...
|
Revision tags: llvmorg-15.0.7 |
|
#
1cb7fba3 |
| 10-Dec-2022 |
Kazu Hirata <kazu@google.com> |
[StaticAnalyzer] Don't use Optional<T>::create (NFC)
std::optional<T> does not have an equivalent method.
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discour
[StaticAnalyzer] Don't use Optional<T>::create (NFC)
std::optional<T> does not have an equivalent method.
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
show more ...
|
#
37a3e98c |
| 10-Dec-2022 |
Kazu Hirata <kazu@google.com> |
[clang] Use std::nullopt instead of None in comments (NFC)
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasval
[clang] Use std::nullopt instead of None in comments (NFC)
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
show more ...
|
#
35b4fbb5 |
| 04-Dec-2022 |
Kazu Hirata <kazu@google.com> |
[clang] Use std::nullopt instead of None in comments (NFC)
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasval
[clang] Use std::nullopt instead of None in comments (NFC)
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
show more ...
|
#
18060066 |
| 03-Dec-2022 |
Kazu Hirata <kazu@google.com> |
[StaticAnalyzer] Use std::nullopt instead of None (NFC)
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the am
[StaticAnalyzer] Use std::nullopt instead of None (NFC)
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to std::optional.
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
show more ...
|
Revision tags: llvmorg-15.0.6 |
|
#
93b98eb3 |
| 23-Nov-2022 |
Balazs Benics <benicsbalazs@gmail.com> |
[analyzer] getBinding should auto-detect type only if it was not given
Casting a pointer to a suitably large integral type by reinterpret-cast should result in the same value as by using the `__buil
[analyzer] getBinding should auto-detect type only if it was not given
Casting a pointer to a suitably large integral type by reinterpret-cast should result in the same value as by using the `__builtin_bit_cast()`. The compiler exploits this: https://godbolt.org/z/zMP3sG683
However, the analyzer does not bind the same symbolic value to these expressions, resulting in weird situations, such as failing equality checks and even results in crashes: https://godbolt.org/z/oeMP7cj8q
Previously, in the `RegionStoreManager::getBinding()` even if `T` was non-null, we replaced it with `TVR->getValueType()` in case the `MR` was `TypedValueRegion`. It doesn't make much sense to auto-detect the type if the type is already given. By not doing the auto-detection, we would just do the right thing and perform the load by that type. This means that we will cast the value to that type.
So, in this patch, I'm proposing to do auto-detection only if the type was null.
Here is a snippet of code, annotated by the previous and new dump values. `LocAsInteger` should wrap the `SymRegion`, since we want to load the address as if it was an integer. In none of the following cases should type auto-detection be triggered, hence we should eventually reach an `evalCast()` to lazily cast the loaded value into that type.
```lang=C++ void LValueToRValueBitCast_dumps(void *p, char (*array)[8]) { clang_analyzer_dump(p); // remained: &SymRegion{reg_$0<void * p>} clang_analyzer_dump(array); // remained: {{&SymRegion{reg_$1<char (*)[8] array>} clang_analyzer_dump((unsigned long)p); // remained: {{&SymRegion{reg_$0<void * p>} [as 64 bit integer]}} clang_analyzer_dump(__builtin_bit_cast(unsigned long, p)); <--------- change #1 // previously: {{&SymRegion{reg_$0<void * p>}}} // now: {{&SymRegion{reg_$0<void * p>} [as 64 bit integer]}} clang_analyzer_dump((unsigned long)array); // remained: {{&SymRegion{reg_$1<char (*)[8] array>} [as 64 bit integer]}} clang_analyzer_dump(__builtin_bit_cast(unsigned long, array)); <--------- change #2 // previously: {{&SymRegion{reg_$1<char (*)[8] array>}}} // now: {{&SymRegion{reg_$1<char (*)[8] array>} [as 64 bit integer]}} } ```
Reviewed By: xazax.hun
Differential Revision: https://reviews.llvm.org/D136603
show more ...
|