| Age | Commit message (Collapse) | Author |
|---|
|
------------------------------------------------------------------------
r321933 | xazax | 2018-01-06 02:51:00 -0800 (Sat, 06 Jan 2018) | 4 lines
[analyzer] Fix some check's output plist not containing the check name
Differential Revision: https://reviews.llvm.org/D41538
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_60@322550 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
functions
This addresses an issue introduced in r183451: since
`removePiecesWithInvalidLocations` is called *after* `adjustCallLocations`,
it is not necessary, and in fact harmful, to have this assertion in
adjustCallLocations.
Addresses rdar://36170689
Differential Revision: https://reviews.llvm.org/D41680
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321682 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Using ARC, strong, weak, and autoreleasing stack variables are implicitly
initialized with nil. This includes variable-length arrays of Objective-C object
pointers. However, in the analyzer we don't zero-initialize them. We used to,
but it accidentally regressed after r289618.
Under ARC, the array variable's initializer within DeclStmt is an
ImplicitValueInitExpr. Environment doesn't maintain any bindings for this
expression kind - instead it always knows that it's a known constant
(0 in our case), so it just returns the known value by calling
SValBuilder::makeZeroVal() (see EnvironmentManager::getSVal().
Commit r289618 had introduced reasonable behavior of SValBuilder::makeZeroVal()
for the arrays, which produces a zero-length compoundVal{}. When such value
is bound to arrays, in RegionStoreManager::bindArray() "remaining" items in the
array are default-initialized with zero, as in
RegionStoreManager::setImplicitDefaultValue(). The similar mechanism works when
an array is initialized by an initializer list that is too short, eg.
int a[3] = { 1, 2 };
would result in a[2] initialized with 0. However, in case of variable-length
arrays it didn't know if any more items need to be added,
because, well, the length is variable.
Add the default binding anyway, regardless of how many actually need
to be added. We don't really care how many, because the default binding covers
the whole array anyway.
Differential Revision: https://reviews.llvm.org/D41478
rdar://problem/35477763
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321290 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The bugreporter::trackNullOrUndefValue() mechanism contains a system of bug
reporter visitors that recursively call each other in order to track where a
null or undefined value came from, where each visitor represents a particular
tracking mechanism (track how the value was stored, track how the value was
returned from a function, track how the value was constrained to null, etc.).
Each visitor is only added once per value it needs to track. Almost. One
exception from this rule would be FindLastStoreBRVisitor that has two operation
modes: it contains a flag that indicates whether null stored values should be
suppressed. Two instances of FindLastStoreBRVisitor with different values of
this flag are considered to be different visitors, so they can be added twice
and produce the same diagnostic twice. This was indeed the case in the affected
test.
With the current logic of this whole machinery, such duplication seems
unavoidable. We should be able to safely add visitors with different flag
values without constructing duplicate diagnostic pieces. Hence the effort
in this commit to de-duplicate diagnostics regardless of what visitors
have produced them.
Differential Revision: https://reviews.llvm.org/D41258
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321135 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
When trying to figure out where a null or undefined value came from,
parentheses and cast expressions are either completely irrelevant, or,
in the case of lvalue-to-rvale cast, straightforwardly lead us in the right
direction when we remove them.
There is a regression that causes a certain diagnostic to appear twice in the
path-notes.cpp test (changed to FIXME). It would be addressed in the next
commit.
Differential revision: https://reviews.llvm.org/D41254
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321133 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
When reporting certain kinds of analyzer warnings, we use the
bugreporter::trackNullOrUndefValue mechanism, which is part of public checker
API, to understand where a zero, null-pointer, or garbage value came from,
which would highlight important events with respect to that value in the
diagnostic path notes, and help us suppress various false positives that result
from values appearing from particular sources.
Previously, we've lost track of the value when it was written into a memory
region that is not a plain variable. Now try to resume tracking in this
situation by finding where the last write to this region has occured.
Differential revision: https://reviews.llvm.org/D41253
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321130 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Since C++17, classes that have base classes can potentially be initialized as
aggregates. Trying to construct such objects through brace initialization was
causing the analyzer to crash when the base class has a non-trivial constructor,
while figuring target region for the base class constructor, because the parent
stack frame didn't contain the constructor of the subclass, because there is
no constructor for subclass, merely aggregate initialization.
This patch avoids the crash, but doesn't provide the actually correct region
for the constructor, which still remains to be fixed. Instead, construction
goes into a fake temporary region which would be immediately discarded. Similar
extremely conservative approach is used for other cases in which the logic for
finding the target region is not yet implemented, including aggregate
initialization with fields instead of base-regions (which is not C++17-specific
but also never worked, just didn't crash).
Differential revision: https://reviews.llvm.org/D40841
rdar://problem/35441058
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321128 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The new check introduced in r318705 is useful, but suffers from a particular
class of false positives, namely, it does not account for
dispatch_barrier_sync() API which allows one to ensure that the asyncronously
executed block that captures a pointer to a local variable does not actually
outlive that variable.
The new check is split into a separate checker, under the name of
alpha.core.StackAddressAsyncEscape, which is likely to get enabled by default
again once these positives are fixed. The rest of the StackAddressEscapeChecker
is still enabled by default.
Differential Revision: https://reviews.llvm.org/D41042
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320455 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Array subscript is almost always an lvalue, except for a few cases where
it is not, such as a subscript into an Objective-C property, or a
return from the function.
This commit prevents crashing in such cases.
Fixes rdar://34829842
Differential Revision: https://reviews.llvm.org/D40584
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@319834 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
RegionStore has special logic to evaluate captured constexpr variables.
However, if the constexpr initializer cannot be evaluated as an integer, the
value is treated as undefined. This leads to false positives when, for example,
a constexpr float is captured by a lambda.
To fix this, treat a constexpr capture that cannot be evaluated as unknown
rather than undefined.
rdar://problem/35784662
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@319638 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Currently clang static analyzer does warn on:
```
int x;
x+=1;
x-=1;
x=x+1;
x=x-1;
```
But does warn on:
```
int x;
x++;
x--;
--x;
++x;
```
This differential should fix that.
Fixes https://bugs.llvm.org/show_bug.cgi?id=35419
Reviewers: dcoughlin, NoQ
Reviewed By: dcoughlin
Subscribers: NoQ, xazax.hun, szepet, cfe-commits, a.sidorin
Tags: #clang
Differential Revision: https://reviews.llvm.org/D40463
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@319411 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
In the original design of the analyzer, it was assumed that a BlockEntrance
doesn't create a new binding on the Store, but this assumption isn't true when
'widen-loops' is set to true. Fix this by finding an appropriate location
BlockEntrace program points.
Patch by Henry Wong!
Differential Revision: https://reviews.llvm.org/D37187
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@319333 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We didn't support the following syntax:
(std::initializer_list<int>){12}
which suddenly produces CompoundLiteralExpr that contains
CXXStdInitializerListExpr.
Lift the assertion and instead pass the value through CompoundLiteralExpr
transparently, as it doesn't add much.
Differential Revision: https://reviews.llvm.org/D39803
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@319058 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We were crashing whenever a C++ pointer-to-member was taken, that was pointing
to a member of an anonymous structure field within a class, eg.
struct A {
struct {
int x;
};
};
// ...
&A::x;
Differential Revision: https://reviews.llvm.org/D39800
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@319055 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Teach the retain-count checker that CoreMedia reference types use
CoreFoundation-style reference counting. This enables the checker
to catch leaks and over releases of those types.
rdar://problem/33599757
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318979 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
non-determinism (attempt 2)
CFG wass built in non-deterministic order due to the fact that indirect
goto labels' declarations (LabelDecl's) are stored in the llvm::SmallSet
container. LabelDecl's are pointers, whose order is not deterministic,
and llvm::SmallSet sorts them by their non-deterministic addresses after
"small" container is exceeded. This leads to non-deterministic processing
of the elements of the container.
The fix is to use llvm::SmallSetVector that was designed to have
deterministic iteration order.
Patch by Ilya Palachev!
Differential Revision: https://reviews.llvm.org/D40073
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318754 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Sorry for the noise.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318753 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
CFG wass built in non-deterministic order due to the fact that indirect
goto labels' declarations (LabelDecl's) are stored in the llvm::SmallSet
container. LabelDecl's are pointers, whose order is not deterministic,
and llvm::SmallSet sorts them by their non-deterministic addresses after
"small" container is exceeded. This leads to non-deterministic processing
of the elements of the container.
The fix is to use llvm::SmallSetVector that was designed to have
deterministic iteration order.
Patch by Ilya Palachev!
Differential Revision: https://reviews.llvm.org/D40073
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318750 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This diff extends StackAddrEscapeChecker
to catch stack addresses leaks via block captures
if the block is executed asynchronously or
returned from a function.
Differential revision: https://reviews.llvm.org/D39438
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318705 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The ObjCGenerics checker warns on a cast when there is no subtyping relationship
between the tracked type of the value and the destination type of the cast. It
does this even if the cast was explicitly written. This means the user can't
write an explicit cast to silence the diagnostic.
This commit treats explicit casts involving generic types as an indication from
the programmer that the Objective-C type system is not rich enough to express
the needed invariant. On explicit casts, the checker now removes any existing
information inferred about the type arguments. Further, it no longer assumes
the casted-to specialized type because the invariant the programmer specifies
in the cast may only hold at a particular program point and not later ones. This
prevents a suppressing cast from requiring a cascade of casts down the
line.
rdar://problem/33603303
Differential Revision: https://reviews.llvm.org/D39711
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318054 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is the issue breaking the postgresql bot, purely by chance exposed
through taint checker, somehow appearing after
https://reviews.llvm.org/D38358 got committed.
The backstory is that the taint checker requests SVal for the value of
the pointer, and analyzer has a "fast path" in the getter to return a
constant when we know that the value is constant.
Unfortunately, the getter requires a cast to get signedness correctly,
and for the pointer `void *` the cast crashes.
This is more of a band-aid patch, as I am not sure what could be done
here "correctly", but it should be applied in any case to avoid the
crash.
Differential Revision: https://reviews.llvm.org/D39862
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@317839 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patches the solver to assume that bitwise OR of an unsigned value with a
constant always produces a value larger-or-equal than the constant, and
bitwise AND with a constant always produces a value less-or-equal than
the constant.
This patch is especially useful in the context of using bitwise
arithmetic for error code encoding: the analyzer would be able to state
that the error code produced using a bitwise OR is non-zero.
Differential Revision: https://reviews.llvm.org/D39707
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@317820 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Do not crash when trying to compute x && y or x || y where x and y are
of a vector type.
For now we do not seem to properly model operations with vectors. In particular,
operations && and || on a pair of vectors are not short-circuit, unlike regular
logical operators, so even our CFG is incorrect.
Avoid the crash, add respective FIXME tests for later.
Differential Revision: https://reviews.llvm.org/D39682
rdar://problem/34317663
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@317700 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Do not crash when trying to define and call a non-standard
strcpy(unsigned char *, unsigned char *) during analysis.
At the same time, do not try to actually evaluate the call.
Differential Revision: https://reviews.llvm.org/D39422
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@317565 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The analyzer's BodyFarm models dispatch_once() by comparing the passed-in
predicate against a known 'done' value. If the predicate does not have that
value, the model updates the predicate to have that value and executes the
passed in block.
Unfortunately, the current model uses the wrong 'done' value: 1 instead of ~0.
This interferes with libdispatch's static inline function _dispatch_once(),
which enables a fast path if the block has already been executed. That function
uses __builtin_assume() to tell the compiler that the done flag is set to ~0 on
exit. When r302880 added modeling of __builtin_assume(), this caused the
analyzer to assume 1 == ~0. This in turn caused the analyzer to never explore any code after a call to dispatch_once().
This patch regains the missing coverage by updating BodyFarm to use the correct
'done' value.
rdar://problem/34413048
Differential Revision: https://reviews.llvm.org/D39691
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@317516 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Addresses https://bugs.llvm.org/show_bug.cgi?id=35075, rdar://35230961
Differential Revision: https://reviews.llvm.org/D39518
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@317293 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The analyzer did not return an UndefVal in case a negative value was left
shifted. I also altered the UndefResultChecker to emit a clear warning in this
case.
Differential Revision: https://reviews.llvm.org/D39423
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316924 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Now when a template is instantiated more times and there is a bug found in the
instantiations the issue hash will be different for each instantiation even if
every other property of the bug (path, message, location) is the same.
This patch aims to resolve this issue. Note that explicit specializations still
generate different hashes but that is intended.
Differential Revision: https://reviews.llvm.org/D38728
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316900 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Extend ExprInspection checker to make it possible to dump the issue hash of
arbitrary expressions. This change makes it possible to make issue hash related
tests more concise and also makes debugging issue hash related problems easier.
Differential Revision: https://reviews.llvm.org/D38844
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316899 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
checker
A patch by zdtorok (Zoltán Dániel Török)!
Differential Revision: https://reviews.llvm.org/D33729
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316892 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316886 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Differential Revision: https://reviews.llvm.org/D37470
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316885 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Added new enum in order to differentiate the warning messages on "misusing" into
3 categories: function calls, moving an object, copying an object. (At the
moment the checker gives the same message in case of copying and moving.)
Additional test cases added as well.
Differential Revision: https://reviews.llvm.org/D38674
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316852 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
handling method calls on base-class sub-objects
An earlier solution from Artem r315301 solves the reset problem, however, the
reports should be handled the same way in case of method calls. We should not
just report the base class of the object where the method was defined but the
whole object.
Fixed false positive which came from not removing the subobjects in case of a
state-resetting function. (Just replaced the State->remove(...) call to
removeFromState(..) which was defined exactly for that purpose.)
Some minor typos fixed in this patch as well which did not worth a whole new
patch in my opinion, so included them here.
Differential Revision: https://reviews.llvm.org/D31538
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316850 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
OpaqueValueExpr in a GNU binary conditional expression.
It's not meaningful for a non-materialized temporary object to be used as a
common subexpression of multiple expressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316836 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The loop unrolling feature aims to track the maximum possible steps a loop can
make. In order to implement this, it investigates the initial value of the
counter variable and the bound number. (It has to be known.)
These numbers are used as llvm::APInts, however, it was not checked if their
bitwidths are the same which lead to some crashes.
This revision solves this problem by extending the "shorter" one (to the length
of the "longer" one).
For the detailed bug report, see: https://bugs.llvm.org/show_bug.cgi?id=34943
Differential Revision: https://reviews.llvm.org/D38922
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316830 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316538 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Differential Revision: https://reviews.llvm.org/D39201
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316402 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
In getLValueElement Base may represent the address of a label
(as in the newly-added test case), in this case it's not a loc::MemRegionVal
and Base.castAs<loc::MemRegionVal>() triggers an assert, this diff makes
getLValueElement return UnknownVal instead.
Differential revision: https://reviews.llvm.org/D39174
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316399 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
std::call_once
Explicitly not supporting functor objects.
Differential Revision: https://reviews.llvm.org/D39031
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316249 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch by: Adam Balogh!
Differential Revision: https://reviews.llvm.org/D39048
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316157 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Remove an option to use a reference type (on by default!) since a
non-reference type is always needed for creating expressions, functions
with multiple boolean parameters are very hard to use, and in general it
was just a booby trap for further crashes.
Furthermore, generalize call_once test case to fix some of the crashes mentioned
https://bugs.llvm.org/show_bug.cgi?id=34869
Also removes std::call_once crash.
Differential Revision: https://reviews.llvm.org/D39015
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316041 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The first attempt, rL315614 was reverted because one libcxx
test broke, and i did not know at the time how to deal with it.
Summary:
Currently, clang only diagnoses completely out-of-range comparisons (e.g. `char` and constant `300`),
and comparisons of unsigned and `0`. But gcc also does diagnose the comparisons with the
`std::numeric_limits<>::max()` / `std::numeric_limits<>::min()` so to speak
Finally Fixes https://bugs.llvm.org/show_bug.cgi?id=34147
Continuation of https://reviews.llvm.org/D37565
Reviewers: rjmccall, rsmith, aaron.ballman
Reviewed By: rsmith
Subscribers: rtrieu, jroelofs, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D38101
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315875 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
In some cases the analyzer didn't expect an array-type variable to be
initialized with anything other than a string literal. The patch essentially
removes the assertion, and ensures relatively sane behavior.
There is a bigger problem with these initializers. Currently our memory model
(RegionStore) is being ordered to initialize the array with a region that
is assumed to be storing the initializer rvalue, and it guesses to copy
the contents of that region to the array variable. However, it would make
more sense for RegionStore to receive the correct initializer in the first
place. This problem isn't addressed with this patch.
rdar://problem/27248428
Differential Revision: https://reviews.llvm.org/D23963
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315750 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The checker used to crash when a mempcpy's length argument is symbolic. In this
case the cast from 'void *' to 'char *' failed because the respective
ElementRegion that represents cast is hard to add on top of the existing
ElementRegion that represents the offset to the last copied byte, while
preseving a sane memory region structure.
Additionally, a few test cases are added (to casts.c) which demonstrate problems
caused by existing sloppy work we do with multi-layer ElementRegions. If said
cast would be modeled properly in the future, these tests would need to be
taken into account.
Differential Revision: https://reviews.llvm.org/D38797
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315742 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
It is not uncommon for the users to make their own wrappers around
CoreFoundation's CFRetain and CFRelease functions that are defensive
against null references. In such cases CFRetain is often incorrectly
marked as CF_RETURNS_RETAINED. Ignore said annotation and treat such
wrappers similarly to the regular CFRetain.
rdar://problem/31699502
Differential Revision: https://reviews.llvm.org/D38877
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315736 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Differential Revision: https://reviews.llvm.org/D38867
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315655 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This reverts r315614,r315615,r315621,r315622
Breaks http://bb9.pgr.jp/#/builders/20/builds/59
/home/bb9/bootstrap-clang-libcxx-lld-i686-linux/llvm-project/libcxx/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp:95:17: error: comparison 'long long' > 9223372036854775807 is always false [-Werror,-Wtautological-constant-compare]
if (max_sec > Lim::max()) return false;
~~~~~~~ ^ ~~~~~~~~~~
/home/bb9/bootstrap-clang-libcxx-lld-i686-linux/llvm-project/libcxx/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp:124:13: error: comparison 'long long' < -9223372036854775808 is always false [-Werror,-Wtautological-constant-compare]
if (sec < Lim::min() || sec > Lim::max()) return false;
~~~ ^ ~~~~~~~~~~
/home/bb9/bootstrap-clang-libcxx-lld-i686-linux/llvm-project/libcxx/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp:124:33: error: comparison 'long long' > 9223372036854775807 is always false [-Werror,-Wtautological-constant-compare]
if (sec < Lim::min() || sec > Lim::max()) return false;
~~~ ^ ~~~~~~~~~~
3 errors generated.
--
I'm not yet sure what is the proper fix.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315631 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Stage-2 builds failed:
error: 'warning' diagnostics expected but not seen:
File /home/buildbot/modules-slave-2/clang-x86_64-linux-selfhost-modules-2/llvm.src/tools/clang/test/Analysis/null-deref-ps.c Line 238: always true
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315622 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Yes, did not check that. Need to do better :(
I do not believe it makes sense to do expect that warning here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315615 91177308-0d34-0410-b5e6-96231b3b80d8
|
