[OpenMP] Add function attribute for triggering data sharing.
Summary:
The backend should only emit data sharing code for the cases where it is needed.
A new function attribute is used by Clang to enable data sharing only for the cases where OpenMP semantics require it and there are variables that need to be shared.
Kelvin Li [Tue, 12 Dec 2017 20:08:12 +0000 (20:08 +0000)]
[OpenMP] Diagnose function name on the link clause
This patch is to add diagnose when a function name is
specified on the link clause. According to the OpenMP
spec, only the list items that exclude the function
name are allowed on the link clause.
Kelvin Li [Tue, 12 Dec 2017 18:33:39 +0000 (18:33 +0000)]
Add --cuda-path to mock a CUDA Toolkit installation to avoid
unexpected error messages for incompatibility between the
default SM level and the support in the installed toolkit.
Don Hinton [Tue, 12 Dec 2017 16:48:35 +0000 (16:48 +0000)]
[debuginfo-tests] Add support for moving debuginfo-tests from clang/test to 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.
Artem Dergachev [Tue, 12 Dec 2017 02:59:09 +0000 (02:59 +0000)]
[analyzer] StackAddrEscape: For now, disable the new async escape checks.
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.
Artem Dergachev [Tue, 12 Dec 2017 02:27:55 +0000 (02:27 +0000)]
[analyzer] In getSVal() API, disable auto-detection of void type as char type.
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.
Craig Topper [Mon, 11 Dec 2017 21:09:19 +0000 (21:09 +0000)]
[Driver][CodeGen] Add -mprefer-vector-width driver option and attribute 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.
Erich Keane [Mon, 11 Dec 2017 19:44:28 +0000 (19:44 +0000)]
PR35586: Relax two asserts that are overly restrictive
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).
Zhihao Yuan [Mon, 11 Dec 2017 18:29:54 +0000 (18:29 +0000)]
P0620 follow-up: deducing `auto` from braced-init-list in new expr
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.
Malcolm Parsons [Mon, 11 Dec 2017 18:00:36 +0000 (18:00 +0000)]
[Sema] Fix crash in unused-lambda-capture warning for VLAs
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.
Alex Lorenz [Sat, 9 Dec 2017 02:27:11 +0000 (02:27 +0000)]
[driver][darwin] Refactor the target selection code, NFC
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.
Akira Hatanaka [Sat, 9 Dec 2017 00:02:37 +0000 (00:02 +0000)]
[CodeGen][X86] Fix handling of __fp16 vectors.
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
Richard Smith [Fri, 8 Dec 2017 22:57:11 +0000 (22:57 +0000)]
Unify implementation of our two different flavours of -Wtautological-compare,
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).
Vedant Kumar [Fri, 8 Dec 2017 19:51:42 +0000 (19:51 +0000)]
[ubsan] array-bounds: Ignore params with constant size
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.
Hans Wennborg [Fri, 8 Dec 2017 16:54:08 +0000 (16:54 +0000)]
Revert "Unify implementation of our two different flavours of -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?
In stdbool.h, define bool, false, true only in gnu++98
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."
Hans Wennborg [Fri, 8 Dec 2017 05:19:12 +0000 (05:19 +0000)]
Revert r320124 "Fold together the in-range and out-of-range portions of -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.
Richard Smith [Fri, 8 Dec 2017 00:45:25 +0000 (00:45 +0000)]
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.
Aaron Ballman [Thu, 7 Dec 2017 21:46:26 +0000 (21:46 +0000)]
Add new language mode flags for C17.
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.
Aaron Ballman [Thu, 7 Dec 2017 21:37:49 +0000 (21:37 +0000)]
Add support for the __has_c_attribute builtin preprocessor macro.
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.
George Rokos [Thu, 7 Dec 2017 20:27:31 +0000 (20:27 +0000)]
[OpenMP] NVPTX: Set default/minimum compute capability to sm_35
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.
Alexey Bataev [Thu, 7 Dec 2017 19:49:28 +0000 (19:49 +0000)]
[OPENMP] Do not capture private variables in the target regions.
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.
Sjoerd Meijer [Thu, 7 Dec 2017 09:54:39 +0000 (09:54 +0000)]
[ARM] ACLE parallel arithmetic and DSP style multiplications
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.
Zhihao Yuan [Thu, 7 Dec 2017 07:03:15 +0000 (07:03 +0000)]
Allow conditions to be decomposed with structured bindings
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.
Yaxun Liu [Thu, 7 Dec 2017 01:39:52 +0000 (01:39 +0000)]
CodeGen: Fix invalid bitcasts for memcpy
CreateCoercedLoad/CreateCoercedStore assumes pointer argument of
memcpy is in addr space 0, which is not correct and causes invalid
bitcasts for triple amdgcn---amdgiz.
Richard Smith [Wed, 6 Dec 2017 19:23:19 +0000 (19:23 +0000)]
Delete special-case "out-of-range" handling for bools, and just use the normal
codepath plus the new "minimum / maximum value of type" diagnostic to get the
same effect.
Move the warning for an in-range but tautological comparison of a constant (0
or 1) against a bool out of -Wtautological-constant-out-of-range-compare into
the more-appropriate -Wtautological-constant-compare.
Jonas Hahnfeld [Wed, 6 Dec 2017 19:15:28 +0000 (19:15 +0000)]
Fix PR35542: Correct adjusting of private reduction variable
The adjustment is calculated with CreatePtrDiff() which returns
the difference in (base) elements. This is passed to CreateGEP()
so make sure that the GEP base has the correct pointer type:
It needs to be a pointer to the base type, not a pointer to a
constant sized array.
Taewook Oh [Wed, 6 Dec 2017 17:00:53 +0000 (17:00 +0000)]
Stringizing raw string literals containing newline
Summary: This patch implements 4.3 of http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4220.pdf. If a raw string contains a newline character, replace each newline character with the \n escape code. Without this patch, included test case (macro_raw_string.cpp) results compilation failure.
[OpenCL] Fix layering violation by getOpenCLTypeAddrSpace
Commit 7ac28eb0a5 / r310911 ("[OpenCL] Allow targets to select address
space per type", 2017-08-15) made Basic depend on AST, introducing a
circular dependency. Break this dependency by adding the
OpenCLTypeKind enum in Basic and map from AST types to this enum in
ASTContext.
Erik Verbruggen [Wed, 6 Dec 2017 09:02:52 +0000 (09:02 +0000)]
[libclang] Add function to get the buffer for a file
This can be used by clients in conjunction with an offset returned by
e.g. clang_getFileLocation. Now those clients do not need to also
open/read the file.
Shoaib Meenai [Tue, 5 Dec 2017 21:49:56 +0000 (21:49 +0000)]
[CMake] Use PRIVATE in target_link_libraries for executables
We currently use target_link_libraries without an explicit scope
specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables.
Dependencies added in this way apply to both the target and its
dependencies, i.e. they become part of the executable's link interface
and are transitive.
Transitive dependencies generally don't make sense for executables,
since you wouldn't normally be linking against an executable. This also
causes issues for generating install export files when using
LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM
library dependencies, which are currently added as interface
dependencies. If clang is in the distribution components but the LLVM
libraries it depends on aren't (which is a perfectly legitimate use case
if the LLVM libraries are being built static and there are therefore no
run-time dependencies on them), CMake will complain about the LLVM
libraries not being in export set when attempting to generate the
install export file for clang. This is reasonable behavior on CMake's
part, and the right thing is for LLVM's build system to explicitly use
PRIVATE dependencies for executables.
Unfortunately, CMake doesn't allow you to mix and match the keyword and
non-keyword target_link_libraries signatures for a single target; i.e.,
if a single call to target_link_libraries for a particular target uses
one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must
also be updated to use those keywords. This means we must do this change
in a single shot. I also fully expect to have missed some instances; I
tested by enabling all the projects in the monorepo (except dragonegg),
and configuring both with and without shared libraries, on both Darwin
and Linux, but I'm planning to rely on the buildbots for other
configurations (since it should be pretty easy to fix those).
Even after this change, we still have a lot of target_link_libraries
calls that don't specify a scope keyword, mostly for shared libraries.
I'm thinking about addressing those in a follow-up, but that's a
separate change IMO.
[analyzer] do not crash on cases where an array subscript is an rvalue
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.
projects / clang / log