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
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
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
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
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
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
> 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
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
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
This adds -std=c17, -std=gnu17, and -std=iso9899:2017 as language mode flags for C17 and updates the value of __STDC_VERSION__ to the value based on the C17 FDIS. Given that this ballot cannot succeed until 2018, it is expected that we (and GCC) will add c18 flags as aliases once the ballot passes.
llvm-svn: 320089
This behaves similar to the __has_cpp_attribute builtin macro in that it allows users to detect whether an attribute is supported with the [[]] spelling syntax, which can be enabled in C with -fdouble-square-bracket-attributes.
llvm-svn: 320088
requested by client
This is a follow up to r319702 which records parsing invocations.
These files are not emitted by default, and the client has to specify the
invocation emission path first.
rdar://35322543
llvm-svn: 320085
The current implementation of the nvptx runtime (to be upstreamed shortly) uses the atomicMax operation on 64-bit integers.
This is only supported in compute capabilities 3.5 and later. I've changed the clang default to sm_35.
Differential Revision: https://reviews.llvm.org/D40977
llvm-svn: 320082
Private variables are completely redefined in the outlined regions, so
we don't need to capture them. Patch adds this behavior to the
target-based regions.
llvm-svn: 320078
Summary:
This enables us to use information in Preprocessor when handling symbol
occurrences.
Reviewers: arphaman, hokein
Reviewed By: hokein
Subscribers: malaperle, cfe-commits
Differential Revision: https://reviews.llvm.org/D40884
llvm-svn: 320030
This is a follow up of r302131, in which we forgot to add SemaChecking
tests. Adding these tests revealed two problems which have been fixed:
- added missing intrinsic __qdbl,
- properly range checking ssat16 and usat16.
Differential Revision: https://reviews.llvm.org/D40888
llvm-svn: 320019
This is a fix for PR35509 in which we crash because we attempt to compute the
alignment of an incomplete type.
Differential Revision: https://reviews.llvm.org/D40895
llvm-svn: 320017
Summary:
This feature was discussed but not yet proposed. It allows a structured binding to appear as a //condition//
if (auto [ok, val] = f(...))
So the user can save an extra //condition// if the statement can test the value to-be-decomposed instead. Formally, it makes the value of the underlying object of the structured binding declaration also the value of a //condition// that is an initialized declaration.
Considering its logicality which is entirely evident from its trivial implementation, I think it might be acceptable to land it as an extension for now before I write the paper.
Reviewers: rsmith, faisalv, aaron.ballman
Reviewed By: rsmith
Subscribers: aaron.ballman, cfe-commits
Differential Revision: https://reviews.llvm.org/D39284
llvm-svn: 320011
CreateCoercedLoad/CreateCoercedStore assumes pointer argument of
memcpy is in addr space 0, which is not correct and causes invalid
bitcasts for triple amdgcn---amdgiz.
It is fixed by using alloca addr space instead.
Differential Revision: https://reviews.llvm.org/D40806
llvm-svn: 320000
Summary:
This is so we can implement concepts per P0734R0. Relevant failing test
cases are disabled.
Reviewers: hubert.reinterpretcast, rsmith, saar.raz, nwilson
Reviewed By: saar.raz
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D40380
Patch by Changyu Li!
llvm-svn: 319992
Malcolm Parsons