These both do the same thing, but some profiling on a
Releast+Asserts build suggests isRVVSizelessBuiltinType() is the
more efficient version so lets keep that one.
An empty structure in C has no way to be initialized, so triggering a
-Wuninitialized warning for a variable of empty structure type is not
actionable for users. This silences the false positive warning, which
matches the behavior of GCC as well.
We no longer diagnose if the structure has no members, or has only
zero-sized members (unnamed bit-fields, zero-sized bit-fields, empty
structure types).
Fixes: https://github.com/llvm/llvm-project/issues/26842
Now that we support outputs from asm goto along indirect edges, we can
remove/revert some code that was added to help warn about the previous
limitation that outputs were not supported along indirect edges.
Reverts some code added in:
commit 72aa619a7fe0 ("Warn of uninitialized variables on asm goto's indirect branch")
commit 3a604fdbcd5f ("[Clang][CFG] check children statements of asm goto")
But keeps+updates the tests.
Link: https://github.com/llvm/llvm-project/issues/53562
Reviewed By: void
Differential Revision: https://reviews.llvm.org/D140508
std::optional::value() has undesired exception checking semantics and is
unavailable in older Xcode (see _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS). The
call sites block std::optional migration.
This makes `ninja clang` work in the absence of llvm::Optional::value.
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
RISC-V vectors are basically vectors, but we use builtin types to
restrict the possible types. Treat them the same as vectors and scalars
for this analysis.
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D136511
A series of unary operators and casts may obscure the variable we're
trying to analyze. Ignore them for the uninitialized value analysis.
Other checks determine if the unary operators result in a valid l-value.
Link: https://github.com/ClangBuiltLinux/linux/issues/1521
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D114848
Summary:
Some libraries use empty function to ignore unused variable warnings, which gets a new warning from `-Wuninitialized-const-reference`, discussed here https://reviews.llvm.org/D79895#2107604.
This patch should fix that.
Reviewers: hans, nick, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: aaron.ballman, riccibruno, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D82425
Summary:
Add a new warning -Wuninitialized-const-reference as a subgroup of -Wuninitialized to address a bug filed here: https://bugs.llvm.org/show_bug.cgi?id=45624
This warning is controlled by -Wuninitialized and can be disabled by -Wno-uninitialized-const-reference.
The warning is diagnosed when passing uninitialized variables as const reference parameters to a function.
Differential Revision: https://reviews.llvm.org/D79895
Summary:
Outputs from an asm goto block cannot be used on the indirect branch.
It's not supported and may result in invalid code generation.
Reviewers: jyknight, nickdesaulniers, hfinkel
Reviewed By: nickdesaulniers
Subscribers: martong, cfe-commits, rnk, craig.topper, hiraditya, rsmith
Tags: #clang
Differential Revision: https://reviews.llvm.org/D71314
Summary:
Clang's "asm goto" feature didn't initially support outputs constraints. That
was the same behavior as gcc's implementation. The decision by gcc not to
support outputs was based on a restriction in their IR regarding terminators.
LLVM doesn't restrict terminators from returning values (e.g. 'invoke'), so
it made sense to support this feature.
Output values are valid only on the 'fallthrough' path. If an output value's used
on an indirect branch, then it's 'poisoned'.
In theory, outputs *could* be valid on the 'indirect' paths, but it's very
difficult to guarantee that the original semantics would be retained. E.g.
because indirect labels could be used as data, we wouldn't be able to split
critical edges in situations where two 'callbr' instructions have the same
indirect label, because the indirect branch's destination would no longer be
the same.
Reviewers: jyknight, nickdesaulniers, hfinkel
Reviewed By: jyknight, nickdesaulniers
Subscribers: MaskRay, rsmith, hiraditya, llvm-commits, cfe-commits, craig.topper, rnk
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D69876
Right now every dataflow algorithm uses its own worklist implementation.
This is a first step to reduce this duplication. Some upcoming
algorithms such as the lifetime analysis is going to use the factored
out implementations.
Differential Revision: https://reviews.llvm.org/D72380
Summary:
Some OpenMP clauses rely on the values of the variables. If the variable
is not initialized and used in OpenMP clauses that depend on the
variables values, it should be reported that the uninitialized variable
is used in the OpenMP clause expression.
This patch adds initial processing for uninitialized variables in OpenMP
constructs. Currently, it checks for use of the uninitialized variables
in the structured blocks.
Reviewers: NoQ, Szelethus, dcoughlin, xazax.hun, a.sidorin, george.karpenkov, szepet
Subscribers: rnkovacs, guansong, jfb, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64356
llvm-svn: 365786
Turn it into a variant class instead. This conversion does indeed save some code
but there's a plan to add support for more kinds of terminators that aren't
necessarily based on statements, and with those in mind it becomes more and more
confusing to have CFGTerminators implicitly convertible to a Stmt *.
Differential Revision: https://reviews.llvm.org/D61814
llvm-svn: 361586
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
This is similar to the LLVM change https://reviews.llvm.org/D46290.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Differential Revision: https://reviews.llvm.org/D46320
llvm-svn: 331834
The implementation is in AnalysisDeclContext.cpp and the class is called
AnalysisDeclContext.
Making those match up has numerous benefits, including:
- Easier jump from header to/from implementation.
- Easily identify filename from class.
Differential Revision: https://reviews.llvm.org/D37500
llvm-svn: 312671
Summary: It breaks the build for the ASTMatchers
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D13893
llvm-svn: 250827
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
llvm-svn: 240270
Previously we'd try to perform checks on the captures from the middle of
parsing the lambda's body, at the point where we detected that a variable
needed to be captured. This was wrong in a number of subtle ways. In
PR23334, we couldn't correctly handle the list of potential odr-uses
resulting from the capture, and our attempt to recover from that resulted
in a use-after-free.
We now defer building the initialization expression until we leave the lambda
body and return to the enclosing context, where the initialization does the
right thing. This patch only covers lambda-expressions, but we should apply
the same change to blocks and captured statements too.
llvm-svn: 235921
`isTrackedVar` has been updated to also track records.
`DeclRefExpr`s appearing on the left side of a comma operator are
ignored, while those appearing on the right side are classified as
`Use`.
Patch by Enrico Pertoso.
llvm-svn: 231068
Fix r216438 to catch more complicated self-initialized in std::move. For
instance, "Foo f = std::move(cond ? OtherFoo : (UNUSED_VALUE, f));"
Make sure that BinaryConditionalOperator, ConditionalOperator, BinaryOperator
with comma operator, and OpaqueValueExpr perform the correct usage forwarding
across the three uninitialized value checkers.
llvm-svn: 216627
to recover the performance after r214064.
Also sorts out the naming for PostOrderCFGView, ReversePostOrderCFGView,
BackwardDataflowWorklist and ForwardDataflowWorklist, to match the accepted
terminology.
Also unifies BackwardDataflowWorklist and ForwardDataflowWorklist to share
the "worklist for prioritization, post-order traversal for fallback" logic,
and to avoid repetitive sorting.
Also cleans up comments in the affected area.
llvm-svn: 215650
