| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
unexpected error messages for incompatibility between the
default SM level and the support in the installed toolkit.
Differential Revision: https://reviews.llvm.org/D40996
llvm-svn: 320506
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
llvm/projects or monorepo.
Summary:
The new version of debuginfo-tests will have it's own
lit.cfg.py file which is incompatible with the one in clang/test.
This change supports both the old and new versions, and can be used
until the bots actually move debuginfo-tests to either clang/test or
the monorepo.
This is a prerequisite for D40971.
Reviewers: zturner, aprantl
Subscribers: mgorny, JDevlieghere, llvm-commits, cfe-commits
Differential Revision: https://reviews.llvm.org/D41055
llvm-svn: 320494
|
| |
|
|
| |
llvm-svn: 320493
|
| |
|
|
| |
llvm-svn: 320489
|
| |
|
|
|
|
|
|
|
|
|
| |
This patch improves detection of ObjC header files.
Right now many ObjC headers, especially short ones, are categorized as C/C++.
Way of filtering still isn't the best, as most likely it should be token-based.
Contributed by jolesiak!
llvm-svn: 320479
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
completions via completion context.
Reviewers: ilya-biryukov, arphaman
Reviewed By: arphaman
Subscribers: nik, cfe-commits
Differential Revision: https://reviews.llvm.org/D40563
llvm-svn: 320471
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 320455
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow-up from r314910. When a checker developer attempts to
dereference a location in memory through ProgramState::getSVal(Loc) or
ProgramState::getSVal(const MemRegion *), without specifying the second
optional QualType parameter for the type of the value he tries to find at this
location, the type is auto-detected from location type. If the location
represents a value beyond a void pointer, we thought that auto-detecting the
type as 'char' is a good idea. However, in most practical cases, the correct
behavior would be to specify the type explicitly, as it is available from other
sources, and the few cases where we actually need to take a 'char' are
workarounds rather than an intended behavior. Therefore, try to fail with an
easy-to-understand assertion when asked to read from a void pointer location.
Differential Revision: https://reviews.llvm.org/D38801
llvm-svn: 320451
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
during CodeGen.
This adds a new command line option -mprefer-vector-width to specify a preferred vector width for the vectorizers. Valid values are 'none' and unsigned integers. The driver will check that it meets those constraints. Specific supported integers will be managed by the targets in the backend.
Clang will take the value and add it as a new function attribute during CodeGen.
This represents the alternate direction proposed by Sanjay in this RFC: http://lists.llvm.org/pipermail/llvm-dev/2017-November/118734.html
The syntax here matches gcc, though gcc treats it as an x86 specific command line argument. gcc only allows values of 128, 256, and 512. I'm not having clang check any values.
Differential Revision: https://reviews.llvm.org/D40230
llvm-svn: 320419
|
| |
|
|
| |
llvm-svn: 320418
|
| |
|
|
|
|
|
|
|
| |
The two asserts are too aggressive. In C++ mode, an
enum is NOT considered an integral type, but an enum value
is allowed to be an enum. This patch relaxes the two asserts
to allow the enum value as well (as typechecking does).
llvm-svn: 320411
|
| |
|
|
| |
llvm-svn: 320410
|
| |
|
|
|
|
| |
It's been failing since r319875.
llvm-svn: 320405
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a side-effect brought in by p0620r0, which allows other placeholder types (derived from `auto` and `decltype(auto)`) to be usable in a `new` expression with a single-clause //braced-init-list// as its initializer (8.3.4 [expr.new]/2). N3922 defined its semantics.
References:
http://wg21.link/p0620r0
http://wg21.link/n3922
Reviewers: rsmith, aaron.ballman
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D39451
llvm-svn: 320401
|
| |
|
|
| |
llvm-svn: 320398
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Clang was crashing when diagnosing an unused-lambda-capture for a VLA because
From.getVariable() is null for the capture of a VLA bound.
Warning about the VLA bound capture is not helpful, so only warn for the VLA
itself.
Fixes: PR35555
Reviewers: aaron.ballman, dim, rsmith
Reviewed By: aaron.ballman, dim
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41016
llvm-svn: 320396
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As reported in llvm bugzilla 32377.
Here’s a patch to add preinclude of stdc-predef.h.
The gcc documentation says “On GNU/Linux, <stdc-predef.h> is pre-included.” See https://gcc.gnu.org/gcc-4.8/porting_to.html;
The preinclude is inhibited with –ffreestanding.
Basically I fixed the failing test cases by adding –ffreestanding which inhibits this behavior.
I fixed all the failing tests, including some in extra/test, there's a separate patch for that which is linked here
Note: this is a recommit after a test failure took down the original (r318669)
Patch By: mibintc
Differential Revision: https://reviews.llvm.org/D34158
llvm-svn: 320391
|
| |
|
|
| |
llvm-svn: 320354
|
| |
|
|
|
|
|
|
|
|
|
| |
microMIPS64R6 is removed from backend, and therefore frontend
will show an error when target is microMIPS64R6.
This is Clang part of patch.
Differential Revision: https://reviews.llvm.org/D35624
llvm-svn: 320351
|
| |
|
|
| |
llvm-svn: 320297
|
| |
|
|
|
|
| |
Apparently libcxx-headers is going away. Fixes PR35584.
llvm-svn: 320271
|
| |
|
|
|
|
| |
This is C++14 with conforming GNU extensions.
llvm-svn: 320250
|
| |
|
|
| |
llvm-svn: 320239
|
| |
|
|
|
|
| |
A target argument should be provided to avoid failures on non-Darwin
llvm-svn: 320238
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The simulator variant of Darwin's platforms is removed in favor of a new
environment field.
The code that selects the platform and the version is split into 4 different
functions instead of being all in one function.
This is an NFC commit, although it slightly improves the
"invalid version number" diagnostic by displaying the environment variable
instead of -m<os>-version-min if the OS version was derived from the
environment.
rdar://35813850
Differential Revision: https://reviews.llvm.org/D41035
llvm-svn: 320235
|
| |
|
|
|
|
| |
Broken in r320232.
llvm-svn: 320233
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Driver, frontend and LLVM codegen for HWASan.
A clone of ASan, basically.
Reviewers: kcc, pcc, alekseyshl
Subscribers: srhines, javed.absar, cfe-commits
Differential Revision: https://reviews.llvm.org/D40936
llvm-svn: 320232
|
| |
|
|
|
|
|
| |
Extend the hashing to functions, which allows detection of function definition
mismatches across modules.
llvm-svn: 320230
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
There is no such library on NetBSD, the corresponding functions like dlopen(3) are in libc.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, vitalybuka, eugenis
Reviewed By: vitalybuka
Subscribers: dberris, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D41021
llvm-svn: 320220
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit fixes a bug in IRGen where it generates completely broken
code for __fp16 vectors on X86. For example when the following code is
compiled:
half4 hv0, hv1, hv2; // these are vectors of __fp16.
void foo221() {
hv0 = hv1 + hv2;
}
clang generates the following IR, in which two i16 vectors are added:
@hv1 = common global <4 x i16> zeroinitializer, align 8
@hv2 = common global <4 x i16> zeroinitializer, align 8
@hv0 = common global <4 x i16> zeroinitializer, align 8
define void @foo221() {
%0 = load <4 x i16>, <4 x i16>* @hv1, align 8
%1 = load <4 x i16>, <4 x i16>* @hv2, align 8
%add = add <4 x i16> %0, %1
store <4 x i16> %add, <4 x i16>* @hv0, align 8
ret void
}
To fix the bug, this commit uses the code committed in r314056, which
modified clang to promote and truncate __fp16 vectors to and from float
vectors in the AST. It also fixes another IRGen bug where a short value
is assigned to an __fp16 variable without any integer-to-floating-point
conversion, as shown in the following example:
__fp16 a;
short b;
void foo1() {
a = b;
}
@b = common global i16 0, align 2
@a = common global i16 0, align 2
define void @foo1() #0 {
%0 = load i16, i16* @b, align 2
store i16 %0, i16* @a, align 2
ret void
}
rdar://problem/20625184
Differential Revision: https://reviews.llvm.org/D40112
llvm-svn: 320215
|
| |
|
|
|
|
|
| |
Also remove unnecessary initialization of out-parameters with this value, so
that MSan is able to catch errors appropriately.
llvm-svn: 320212
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and fold together into a single function.
In so doing, fix a handful of remaining bugs where we would report false
positives or false negatives if we promote a signed value to an unsigned type
for the comparison.
This re-commits r320122 and r320124, minus two changes:
* Comparisons between a constant and a non-constant expression of enumeration
type never warn, not even if the constant is out of range. We should be
warning about the creation of such a constant, not about its use.
* We do not use more precise bit-widths for comparisons against bit-fields.
The more precise diagnostics probably are the right thing, but we should
consider moving them under their own warning flag.
Other than the refactoring, this patch should only change the behavior for the
buggy cases (where the warnings didn't take into account that promotion from
signed to unsigned can leave a range of inaccessible values in the middle of
the promoted type).
llvm-svn: 320211
|
| |
|
|
|
|
| |
minor fixes (NFC).
llvm-svn: 320207
|
| |
|
|
|
|
|
| |
Initial patch could cause trouble in the optimized code because of the
incorrectly generated lifetime intrinsics.
llvm-svn: 320191
|
| |
|
|
|
|
|
|
|
|
| |
This is a follow-up to r320128. Eli pointed out that there is some gray
area in the language standard about whether the constant size is exact,
or a lower bound.
https://reviews.llvm.org/D40940
llvm-svn: 320185
|
| |
|
|
| |
llvm-svn: 320168
|
| |
|
|
|
|
| |
The -ldl library is missing on NetBSD too, make the comment more generic.
llvm-svn: 320165
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-Wtautological-compare."
> Unify implementation of our two different flavours of -Wtautological-compare.
>
> In so doing, fix a handful of remaining bugs where we would report false
> positives or false negatives if we promote a signed value to an unsigned type
> for the comparison.
This caused a new warning in Chromium:
../../base/trace_event/trace_log.cc:1545:29: error: comparison of constant 64
with expression of type 'unsigned int' is always true
[-Werror,-Wtautological-constant-out-of-range-compare]
DCHECK(handle.event_index < TraceBufferChunk::kTraceBufferChunkSize);
~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The 'unsigned int' is really a 6-bit bitfield, which is why it's always
less than 64.
I thought we didn't use to warn (with out-of-range-compare) when comparing
against the boundaries of a type?
llvm-svn: 320162
|
| |
|
|
|
|
| |
Host + default devices codegen for `target teams distribute` directive.
llvm-svn: 320149
|
| |
|
|
|
|
|
|
|
|
| |
GCC has meanwhile corrected that with the similar
<https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=216679> "C++11
explicitly forbids macros for bool, true and false."
Differential Revision: https://reviews.llvm.org/D40167
llvm-svn: 320135
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-Wtautological-compare."
This broke Chromium:
../../base/trace_event/trace_log.cc:1545:29: error: comparison of constant 64
with expression of type 'unsigned int' is always true
[-Werror,-Wtautological-constant-out-of-range-compare]
DCHECK(handle.event_index < TraceBufferChunk::kTraceBufferChunkSize);
~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The 'unsigned int' is really a 6-bit bitfield, which is why it's always
less than 63.
Did this use to fall under the "in-range" case before? I thought we
didn't use to warn when comparing against the boundaries of a type.
llvm-svn: 320133
|
| |
|
|
|
|
|
|
|
|
|
|
| |
There is no way to apply sanitizer suppressions to ObjC blocks. A
reasonable default is to have blocks inherit their parent's sanitizer
options.
rdar://32769634
Differential Revision: https://reviews.llvm.org/D40668
llvm-svn: 320132
|
| |
|
|
|
|
| |
-std=c17.
llvm-svn: 320131
|
| |
|
|
|
|
|
|
|
| |
Teach UBSan's bounds check to opportunistically use pass_object_size
information to check array accesses.
rdar://33272922
llvm-svn: 320128
|
| |
|
|
| |
llvm-svn: 320124
|
| |
|
|
|
|
|
|
| |
In so doing, fix a handful of remaining bugs where we would report false
positives or false negatives if we promote a signed value to an unsigned type
for the comparison.
llvm-svn: 320122
|
| |
|
|
| |
llvm-svn: 320115
|
| |
|
|
| |
llvm-svn: 320114
|
| |
|
|
| |
llvm-svn: 320113
|
| |
|
|
| |
llvm-svn: 320112
|