[analyzer][NFC] Migrate nonloc::ConcreteInt to use APSIntPtr (2/4) (#120436)

[analyzer] Fix wrong `builtin_*_overflow` return type (#111253)

`builtin_*_overflow` functions return `_Bool` according to [1].
`BuiltinFunctionChecker` was using `makeTruthVal` w/o specifying
expli

[analyzer] Fix wrong `builtin_*_overflow` return type (#111253)

`builtin_*_overflow` functions return `_Bool` according to [1].
`BuiltinFunctionChecker` was using `makeTruthVal` w/o specifying
explicit type, which creates an `int` value, since it's the type of any
compassion according to C standard.

Fix it by directly passing `BoolTy` to `makeTruthVal`

Closes: #111147

[1]
https://clang.llvm.org/docs/LanguageExtensions.html#checked-arithmetic-builtins

show more ...

[analyzer] Model overflow builtins (#102602)

Add basic support for `builtin_*_overflow` primitives.

These helps a lot for checking custom calloc-like functions with
inlinable body. Without such s

[analyzer] Model overflow builtins (#102602)

Add basic support for `builtin_*_overflow` primitives.

These helps a lot for checking custom calloc-like functions with
inlinable body. Without such support code like

```c
#include <stddef.h>
#include <stdlib.h>

static void *myMalloc(size_t a1, size_t a2)
{
size_t res;

if (__builtin_mul_overflow(a1, a2, &res))
return NULL;
return malloc(res);
}

void test(void)
{
char *ptr = myMalloc(10, 1);
ptr[20] = 10;
}
````

does not trigger any warnings.

show more ...

[analyzer] Model builtin-like functions as builtin functions (#99886)

Some template function instantiations don't have a body, even though
their templates did have a body.
Examples are: `std::move

[analyzer] Model builtin-like functions as builtin functions (#99886)

Some template function instantiations don't have a body, even though
their templates did have a body.
Examples are: `std::move`, `std::forward`, `std::addressof` etc.

They had bodies before
https://github.com/llvm/llvm-project/commit/72315d02c432a0fe0acae9c96c69eac8d8e1a9f6

After that change, the sentiment was that these special functions should
be considered and treated as builtin functions.

Fixes #94193

CPP-5358

show more ...

[analyzer] Handle builtin functions in MallocChecker (#88416)

This commit ensures that the `CallDescription`s in `MallocChecker` are
matched with the mode `CDM::CLibrary`, so:
- they don't match m

[analyzer] Handle builtin functions in MallocChecker (#88416)

This commit ensures that the `CallDescription`s in `MallocChecker` are
matched with the mode `CDM::CLibrary`, so:
- they don't match methods or functions within user-defined namespaces;
- they also match builtin variants of these functions (if any), so the
checker can model `__builtin_alloca()` like `alloca()`.

This change fixes https://github.com/llvm/llvm-project/issues/81597. New
tests were added to verify that `std::malloc` and `std::free` (from
`<cstdlib>`) are modeled, but a method that's named e.g. `free` isn't
confused with the memory release function.

The responsibility for modeling `__builtin_alloca` and
`__builtin_alloca_with_align` was moved from `BuiltinFunctionChecker` to
`MallocChecker`, to avoid buggy interactions between the checkers and
ensure that the builtin and non-builtin variants are handled by exactly
the same logic.

This change might be a step backwards for the users who don't have
`unix.Malloc` enabled; but I suspect that `__builtin_alloca()` is so
rare that it would be a waste of time to implement backwards
compatibility for them.

There were several test files that relied on `__builtin_alloca()` calls
to get an `AllocaRegion`, these were modified to enable `unix.Malloc`.
One of these files (cxx-uninitialized-object-ptr-ref.cpp) had some tests
that relied on the fact that `malloc()` was treated as a "black box" in
them, these were updated to use `calloc()` (to get initialized memory)
and `free()` (to avoid memory leak reports).

While I was developing this change, I found a very suspicious assert in
`MallocChecker`. As it isn't blocking the goals of this commit, I just
marked it with a FIXME, but I'll try to investigate and fix it in a
follow-up change.

show more ...

[analyzer] Model Microsoft "__assume" in the same way as clang "__builtin_assume"

[analyzer] Use AllocaRegion in MallocChecker (#72402)

...to model the results of alloca() and _alloca() calls. Previously it
acted as if these functions were returning memory from the heap, which

[analyzer] Use AllocaRegion in MallocChecker (#72402)

...to model the results of alloca() and _alloca() calls. Previously it
acted as if these functions were returning memory from the heap, which
led to alpha.security.ArrayBoundV2 producing incorrect messages.

show more ...

[Clang] Add __builtin_function_start

Control-Flow Integrity (CFI) replaces references to address-taken
functions with pointers to the CFI jump table. This is a problem
for low-level code, such as op

[Clang] Add __builtin_function_start

Control-Flow Integrity (CFI) replaces references to address-taken
functions with pointers to the CFI jump table. This is a problem
for low-level code, such as operating system kernels, which may
need the address of an actual function body without the jump table
indirection.

This change adds the __builtin_function_start() builtin, which
accepts an argument that can be constant-evaluated to a function,
and returns the address of the function body.

Link: https://github.com/ClangBuiltLinux/linux/issues/1353

Depends on D108478

Reviewed By: pcc, rjmccall

Differential Revision: https://reviews.llvm.org/D108479

show more ...

[analyzer] DynamicSize: Rename 'size' to 'extent'

[analyzer] DynamicSize: Store the dynamic size

This patch introduces a way to store the size.

Reviewed By: NoQ

Differential Revision: https://reviews.llvm.org/D69726

Fix warning caused by __builtin_expect_with_probability was not handled
in places such as constant folding

Previously some places that should have handled
__builtin_expect_with_probability is missin

Fix warning caused by __builtin_expect_with_probability was not handled
in places such as constant folding

Previously some places that should have handled
__builtin_expect_with_probability is missing, so in some case it acts
differently than __builtin_expect.
For example it was not handled in constant folding, thus in the
following program, the "if" condition should be constantly true and
folded, but previously it was not handled and cause warning "control may
reach end of non-void function" (while __builtin_expect does not):

__attribute__((noreturn)) extern void bar();
int foo(int x, int y) {
if (y) {
if (__builtin_expect_with_probability(1, 1, 1))
bar();
}
else
return 0;
}

Now it's fixed.

Differential Revisions: https://reviews.llvm.org/D83362

show more ...

[analyzer][NFC] Change LangOptions to CheckerManager in the shouldRegister* functions

Some checkers may not only depend on language options but also analyzer options.
To make this possible this patc

[analyzer][NFC] Change LangOptions to CheckerManager in the shouldRegister* functions

Some checkers may not only depend on language options but also analyzer options.
To make this possible this patch changes the parameter of the shouldRegister*
function to CheckerManager to be able to query the analyzer options when
deciding whether the checker should be registered.

Differential Revision: https://reviews.llvm.org/D75271

show more ...

[analyzer] DynamicSize: Remove 'getExtent()' from regions

Summary:
This patch introduces a placeholder for representing the dynamic size of
regions. It also moves the `getExtent()` method of `SubReg

[analyzer] DynamicSize: Remove 'getExtent()' from regions

Summary:
This patch introduces a placeholder for representing the dynamic size of
regions. It also moves the `getExtent()` method of `SubRegions` to the
`MemRegionManager` as `getStaticSize()`.

Reviewed By: NoQ

Differential Revision: https://reviews.llvm.org/D69540

show more ...

[analyzer] NFC: Change evalCall() to provide a CallEvent.

This changes the checker callback signature to use the modern, easy to
use interface. Additionally, this unblocks future work on allowing
ch

[analyzer] NFC: Change evalCall() to provide a CallEvent.

This changes the checker callback signature to use the modern, easy to
use interface. Additionally, this unblocks future work on allowing
checkers to implement evalCall() for calls that don't correspond to any
call-expression or require additional information that's only available
as part of the CallEvent, such as C++ constructors and destructors.

Differential Revision: https://reviews.llvm.org/D62440

llvm-svn: 363893

show more ...

[analyzer] When failing to evaluate a __builtin_constant_p, presume it's false.

__builtin_constant_p(x) is a compiler builtin that evaluates to 1 when
its argument x is a compile-time constant and t

[analyzer] When failing to evaluate a __builtin_constant_p, presume it's false.

__builtin_constant_p(x) is a compiler builtin that evaluates to 1 when
its argument x is a compile-time constant and to 0 otherwise. In CodeGen
it is simply lowered to the respective LLVM intrinsic. In the Analyzer
we've been trying to delegate modeling to Expr::EvaluateAsInt, which is
allowed to sometimes fail for no apparent reason.

When it fails, let's conservatively return false. Modeling it as false
is pretty much never wrong, and it is only required to return true
on a best-effort basis, which every user should expect.

Fixes VLAChecker false positives on code that tries to emulate
static asserts in C by constructing a VLA of dynamic size -1 under the
assumption that this dynamic size is actually a constant
in the sense of __builtin_constant_p.

Differential Revision: https://reviews.llvm.org/D60110

llvm-svn: 357557

show more ...

Add a new builtin: __builtin_dynamic_object_size

This builtin has the same UI as __builtin_object_size, but has the
potential to be evaluated dynamically. It is meant to be used as a
drop-in replace

Add a new builtin: __builtin_dynamic_object_size

This builtin has the same UI as __builtin_object_size, but has the
potential to be evaluated dynamically. It is meant to be used as a
drop-in replacement for libraries that use __builtin_object_size when
a dynamic checking mode is enabled. For instance,
__builtin_object_size fails to provide any extra checking in the
following function:

void f(size_t alloc) {
char* p = malloc(alloc);
strcpy(p, "foobar"); // expands to __builtin___strcpy_chk(p, "foobar", __builtin_object_size(p, 0))
}

This is an overflow if alloc < 7, but because LLVM can't fold the
object size intrinsic statically, it folds __builtin_object_size to
-1. With __builtin_dynamic_object_size, alloc is passed through to
__builtin___strcpy_chk.

rdar://32212419

Differential revision: https://reviews.llvm.org/D56760

llvm-svn: 352665

show more ...

[analyzer] Supply all checkers with a shouldRegister function

Introduce the boolean ento::shouldRegister##CHECKERNAME(const LangOptions &LO)
function very similarly to ento::register##CHECKERNAME. T

[analyzer] Supply all checkers with a shouldRegister function

Introduce the boolean ento::shouldRegister##CHECKERNAME(const LangOptions &LO)
function very similarly to ento::register##CHECKERNAME. This will force every
checker to implement this function, but maybe it isn't that bad: I saw a lot of
ObjC or C++ specific checkers that should probably not register themselves based
on some LangOptions (mine too), but they do anyways.

A big benefit of this is that all registry functions now register their checker,
once it is called, registration is guaranteed.

This patch is a part of a greater effort to reinvent checker registration, more
info here: D54438#1315953

Differential Revision: https://reviews.llvm.org/D55424

llvm-svn: 352277

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
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

show more ...

[analyzer][NFC] Move CheckerRegistry from the Core directory to Frontend

ClangCheckerRegistry is a very non-obvious, poorly documented, weird concept.
It derives from CheckerRegistry, and is placed

[analyzer][NFC] Move CheckerRegistry from the Core directory to Frontend

ClangCheckerRegistry is a very non-obvious, poorly documented, weird concept.
It derives from CheckerRegistry, and is placed in lib/StaticAnalyzer/Frontend,
whereas it's base is located in lib/StaticAnalyzer/Core. It was, from what I can
imagine, used to circumvent the problem that the registry functions of the
checkers are located in the clangStaticAnalyzerCheckers library, but that
library depends on clangStaticAnalyzerCore. However, clangStaticAnalyzerFrontend
depends on both of those libraries.

One can make the observation however, that CheckerRegistry has no place in Core,
it isn't used there at all! The only place where it is used is Frontend, which
is where it ultimately belongs.

This move implies that since
include/clang/StaticAnalyzer/Checkers/ClangCheckers.h only contained a single function:

class CheckerRegistry;

void registerBuiltinCheckers(CheckerRegistry &registry);

it had to re purposed, as CheckerRegistry is no longer available to
clangStaticAnalyzerCheckers. It was renamed to BuiltinCheckerRegistration.h,
which actually describes it a lot better -- it does not contain the registration
functions for checkers, but only those generated by the tblgen files.

Differential Revision: https://reviews.llvm.org/D54436

llvm-svn: 349275

show more ...

Revert "Revert r347417 "Re-Reinstate 347294 with a fix for the failures.""

It seems the two failing tests can be simply fixed after r348037

Fix 3 cases in Analysis/builtin-functions.cpp
Delete the

Revert "Revert r347417 "Re-Reinstate 347294 with a fix for the failures.""

It seems the two failing tests can be simply fixed after r348037

Fix 3 cases in Analysis/builtin-functions.cpp
Delete the bad CodeGen/builtin-constant-p.c for now

llvm-svn: 348053

show more ...

Revert r347417 "Re-Reinstate 347294 with a fix for the failures."

Kept the "indirect_builtin_constant_p" test case in test/SemaCXX/constant-expression-cxx1y.cpp
while we are investigating why the fo

Revert r347417 "Re-Reinstate 347294 with a fix for the failures."

Kept the "indirect_builtin_constant_p" test case in test/SemaCXX/constant-expression-cxx1y.cpp
while we are investigating why the following snippet fails:

extern char extern_var;
struct { int a; } a = {__builtin_constant_p(extern_var)};

llvm-svn: 348039

show more ...

Re-commit r347417 "Re-Reinstate 347294 with a fix for the failures."

This was reverted in r347656 due to me thinking it caused a miscompile of
Chromium. Turns out it was the Chromium code that was b

Re-commit r347417 "Re-Reinstate 347294 with a fix for the failures."

This was reverted in r347656 due to me thinking it caused a miscompile of
Chromium. Turns out it was the Chromium code that was broken.

llvm-svn: 347756

show more ...

Revert r347417 "Re-Reinstate 347294 with a fix for the failures."

This caused a miscompile in Chrome (see crbug.com/908372) that's
illustrated by this small reduction:

static bool f(int *a, int *

Revert r347417 "Re-Reinstate 347294 with a fix for the failures."

This caused a miscompile in Chrome (see crbug.com/908372) that's
illustrated by this small reduction:

static bool f(int *a, int *b) {
return !__builtin_constant_p(b - a) || (!(b - a));
}

int arr[] = {1,2,3};

bool g() {
return f(arr, arr + 3);
}

$ clang -O2 -S -emit-llvm a.cc -o -

g() should return true, but after r347417 it became false for some reason.

This also reverts the follow-up commits.

r347417:
> Re-Reinstate 347294 with a fix for the failures.
>
> Don't try to emit a scalar expression for a non-scalar argument to
> __builtin_constant_p().
>
> Third time's a charm!

r347446:
> The result of is.constant() is unsigned.

r347480:
> A __builtin_constant_p() returns 0 with a function type.

r347512:
> isEvaluatable() implies a constant context.
>
> Assume that we're in a constant context if we're asking if the expression can
> be compiled into a constant initializer. This fixes the issue where a
> __builtin_constant_p() in a compound literal was diagnosed as not being
> constant, even though it's always possible to convert the builtin into a
> constant.

r347531:
> A "constexpr" is evaluated in a constant context. Make sure this is reflected
> if a __builtin_constant_p() is a part of a constexpr.

llvm-svn: 347656

show more ...

Re-Reinstate 347294 with a fix for the failures.

Don't try to emit a scalar expression for a non-scalar argument to
__builtin_constant_p().

Third time's a charm!

llvm-svn: 347417

Revert r347364 again, the fix was incomplete.

llvm-svn: 347389