Summary:
Convert clang::LangAS to a strongly typed enum
Currently both clang AST address spaces and target specific address spaces
are represented as unsigned which can lead to subtle errors if the wrong
type is passed. It is especially confusing in the CodeGen files as it is
not possible to see what kind of address space should be passed to a
function without looking at the implementation.
I originally made this change for our LLVM fork for the CHERI architecture
where we make extensive use of address spaces to differentiate between
capabilities and pointers. When merging the upstream changes I usually
run into some test failures or runtime crashes because the wrong kind of
address space is passed to a function. By converting the LangAS enum to a
C++11 we can catch these errors at compile time. Additionally, it is now
obvious from the function signature which kind of address space it expects.
I found the following errors while writing this patch:
- ItaniumRecordLayoutBuilder::LayoutField was passing a clang AST address
space to TargetInfo::getPointer{Width,Align}()
- TypePrinter::printAttributedAfter() prints the numeric value of the
clang AST address space instead of the target address space.
However, this code is not used so I kept the current behaviour
- initializeForBlockHeader() in CGBlocks.cpp was passing
LangAS::opencl_generic to TargetInfo::getPointer{Width,Align}()
- CodeGenFunction::EmitBlockLiteral() was passing a AST address space to
TargetInfo::getPointerWidth()
- CGOpenMPRuntimeNVPTX::translateParameter() passed a target address space
to Qualifiers::addAddressSpace()
- CGOpenMPRuntimeNVPTX::getParameterAddress() was using
llvm::Type::getPointerTo() with a AST address space
- clang_getAddressSpace() returns either a LangAS or a target address
space. As this is exposed to C I have kept the current behaviour and
added a comment stating that it is probably not correct.
Other than this the patch should not cause any functional changes.
Aaron Ballman [Sun, 15 Oct 2017 15:01:42 +0000 (15:01 +0000)]
Add -f[no-]double-square-bracket-attributes as new driver options to control use of [[]] attributes in all language modes. This is the initial implementation of WG14 N2165, which is a proposal to add [[]] attributes to C2x, but also allows you to enable these attributes in C++98, or disable them in C++11 or later.
Faisal Vali [Sun, 15 Oct 2017 01:26:26 +0000 (01:26 +0000)]
[c++2a] Implement P0306 __VA_OPT__ (Comma omission and comma deletion)
This patch implements an extension to the preprocessor:
__VA_OPT__(contents) --> which expands into its contents if variadic arguments are supplied to the parent macro, or behaves as an empty token if none.
- Currently this feature is only enabled for C++2a (this could be enabled, with some careful tweaks, for other dialects with the appropriate extension or compatibility warnings)
- The patch was reviewed here: https://reviews.llvm.org/D35782 and asides from the above (and moving some of the definition and expansion recognition logic into the corresponding state machines), I believe I incorporated all of Richard's suggestions.
A few technicalities (most of which were clarified through private correspondence between rsmith, hubert and thomas) are worth mentioning. Given:
#define F(a,...) a #__VA_OPT__(a ## a) a ## __VA_OPT__(__VA_ARGS__)
- The call F(,) Does not supply any tokens for the variadic arguments and hence VA_OPT behaves as a placeholder.
- When expanding VA_OPT (for e.g. F(,1) token pasting occurs eagerly within its contents if the contents need to be stringified.
- A hash or a hashhash prior to VA_OPT does not inhibit expansion of arguments if they are the first token within VA_OPT.
- When a variadic argument is supplied, argument substitution occurs within the contents as does stringification - and these resulting tokens are inserted back into the macro expansions token stream just prior to the entire stream being rescanned and concatenated.
See wg21.link/P0306 for further details on the feature.
Acknowledgment: This patch would have been poorer if not for Richard Smith's usual thoughtful analysis and feedback.
Yaxun Liu [Sat, 14 Oct 2017 12:23:50 +0000 (12:23 +0000)]
[OpenCL] Emit enqueued block as kernel
In OpenCL the kernel function and non-kernel function has different calling conventions.
For certain targets they have different argument ABIs. Also kernels have special function
attributes and metadata for runtime to launch them.
The blocks passed to enqueue_kernel is supposed to be executed as kernels. As such,
the block invoke function should be emitted as kernel with proper calling convention and
argument ABI.
This patch emits enqueued block as kernel. If a block is both called directly and passed
to enqueue_kernel, separate functions will be generated.
Benjamin Kramer [Sat, 14 Oct 2017 01:30:49 +0000 (01:30 +0000)]
[Sema] Warn about unused variables if we can constant evaluate the initializer.
If the variable construction can be constant evaluated it doesn't have
side effects, so removing it is always safe. We only try to evaluate
variables that are unused, there should be no impact on compile time.
Vedant Kumar [Sat, 14 Oct 2017 01:23:30 +0000 (01:23 +0000)]
[ubsan] Don't emit function signatures for non-static member functions
The function sanitizer only checks indirect calls through function
pointers. This excludes all non-static member functions (constructor
calls, calls through thunks, etc. all use a separate code path). Don't
emit function signatures for functions that won't be checked.
Apart from cutting down on code size, this should fix a regression on
Linux caused by r313096. For context, see the mailing list discussion:
r313096 - [ubsan] Function Sanitizer: Don't require writable text segments
Benjamin Kramer [Fri, 13 Oct 2017 22:14:34 +0000 (22:14 +0000)]
[Sema] Avoid iterator invalidation when code completing.
It's possible for the code completion consumer to add new decls to the
current scope while lookup happens on it. Avoid this by making a copy
first.
Sadly I wasn't able to get a self-contained test case for this as it
requires code completion + precompiled preamble + the stars aligning to
deserialize at exactly the right time.
George Karpenkov [Fri, 13 Oct 2017 22:03:09 +0000 (22:03 +0000)]
Allow building libFuzzer in two-stage compiler-rt build
When LLVM_BUILD_EXTERNAL_COMPILER_RT option is set to true,
all of projects in compiler-rt are built with a freshly-built compiler using
a recursive CMake invocation.
(e.g. that's how compiler-rt is used in Swift)
Just now I have noticed that libFuzzer binaries were missing in such a case,
and ninja fuzzer returned "no such target", while ninja asan worked just fine.
To my surprise, the list of allowed targets was actually hardcoded in Clang!
While the current setup is clearly suboptimal, for the lack of a better fix
I'm just adding `fuzzer` to a list of `compiler-rt` targets.
Artem Dergachev [Fri, 13 Oct 2017 20:54:56 +0000 (20:54 +0000)]
[analyzer] pr28449: Fix support for various array initializers.
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.
Artem Dergachev [Fri, 13 Oct 2017 20:11:00 +0000 (20:11 +0000)]
[analyzer] CStringChecker: pr34460: Avoid a crash when a cast is not modeled.
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.
The `nan` family of functions will inspect the contents of the parameter
that they are passed. As a result, the function cannot be annotated as
`const`. The documentation of the `const` attribute explicitly states
this:
Note that a function that has pointer arguments and examines the data
pointed to must not be declared const.
Adjust the annotations on this family of functions.
Alex Lorenz [Fri, 13 Oct 2017 19:42:05 +0000 (19:42 +0000)]
[clang-refactor] Apply source replacements
This commit actually brings clang-refactor to a usable state as it can now
apply the refactoring changes to source files.
The -selection option is now also fully supported.
Artem Dergachev [Fri, 13 Oct 2017 19:10:42 +0000 (19:10 +0000)]
[analyzer] RetainCount: Ignore annotations on user-made CFRetain wrappers.
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.
Yaxun Liu [Fri, 13 Oct 2017 03:37:48 +0000 (03:37 +0000)]
[OpenCL] Add LangAS::opencl_private to represent private address space in AST
Currently Clang uses default address space (0) to represent private address space for OpenCL
in AST. There are two issues with this:
Multiple address spaces including private address space cannot be diagnosed.
There is no mangling for default address space. For example, if private int* is emitted as
i32 addrspace(5)* in IR. It is supposed to be mangled as PUAS5i but it is mangled as
Pi instead.
This patch attempts to represent OpenCL private address space explicitly in AST. It adds
a new enum LangAS::opencl_private and adds it to the variable types which are implicitly
private:
automatic variables without address space qualifier
function parameter
pointee type without address space qualifier (OpenCL 1.2 and below)
[clang] Enable clang build with LLVM_BUILD_INSTRUMENTED without setting LLVM_PROFTDATA
At the moment if LLVM_BUILD_INSTRUMENTED is set to True
one has to set LLVM_PROFTDATA even if it's not really used
(because of message(FATAL_ERROR ...)).
Building the instrumented version of Clang can be useful even if
one doesn't plan to build the target generate-profdata
(currently that target would only compile utils/perf-training/cxx/hello_world.cpp).
For example, one can run the instrumented version of Clang
via a separate build system against a different codebase,
collect/analyze the profiles and merge them by llvm-profdata later.
Reid Kleckner [Fri, 13 Oct 2017 00:53:02 +0000 (00:53 +0000)]
[MS] Don't bail on replacing dllimport vbase dtors with base dtors
Fix PR32990 by effectively reverting r283063 and solving it a different
way.
We want to limit the hack to not replace equivalent available_externally
dtors specifically to libc++, which uses always_inline. It seems certain
versions of libc++ do not provide all the symbols that an explicit
template instantiation is expected to provide.
If we get to the code that forms a real alias, only *then* check if this
is available_externally, and do that by asking a better question, which
is "is this a declaration for the linker?", because *that's* what means
we can't form an alias to it.
As a follow-on simplification, remove the InEveryTU parameter. Its last
use guarded this code for forming aliases, but we should never form
aliases to declarations, regardless of what we know about every TU.
The test used to fail because the loop in CheckObjCMethodOverrides would
merge attribute ns_returns_retained on methods while checking whether
the overriding methods were compatible. Since OverrideSearch::Overridden
is a SmallPtrSet and the order in which the elements of the set are
visited is non-deterministic, the test would fail when method 'clone' of
the protocol 'F18P' was visited before F18(Cat)'s method 'clone' was
visited.
Erich Keane [Thu, 12 Oct 2017 23:01:53 +0000 (23:01 +0000)]
[Sema][Crash] Correctly handle an non-dependent noexcept expr in function template
It seems that all of the other templated cases are handled correctly,
however the function template case was not correctly handled. This
patch recovers from this condition by setting the function to noexcept
after diagnosing. Previously it simply set NoexceptExpr to null,
which caused an Assert when this was evaluated during substitution.
Zachary Turner [Thu, 12 Oct 2017 21:56:05 +0000 (21:56 +0000)]
[lit] Raise the logic for enabling clang & lld substitutions to llvm.
This paves the way for other projects which might /use/ clang or
lld but not necessarily need to the full set of functionality
available to clang and lld tests to be able to have a basic set
of substitutions that allow a project to run the clang or lld
executables.
Roman Lebedev [Thu, 12 Oct 2017 21:15:26 +0000 (21:15 +0000)]
[Analysis] Un-silence -Wtautological-unsigned-zero-compare in null-deref-ps.c
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
Roman Lebedev [Thu, 12 Oct 2017 20:16:51 +0000 (20:16 +0000)]
[Sema] Diagnose tautological comparison with type's min/max values
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
Alexey Bataev [Thu, 12 Oct 2017 13:51:32 +0000 (13:51 +0000)]
[OPENMP] Fix PR34925: Fix getting thread_id lvalue for inlined regions
in C.
If we try to get the lvalue for thread_id variables in inlined regions,
we did not use the correct version of function. Fixed this bug by adding
overrided version of the function getThreadIDVariableLValue for inlined
regions.
Ivan A. Kosarev [Thu, 12 Oct 2017 11:29:46 +0000 (11:29 +0000)]
[CodeGen] Generate TBAA info along with LValue base info
This patch enables explicit generation of TBAA information in all
cases where LValue base info is propagated or constructed in
non-trivial ways. Eventually, we will consider each of these
cases to make sure the TBAA information is correct and not too
conservative. For now, we just fall back to generating TBAA info
from the access type.
This patch should not bring in any functional changes.
This is part of D38126 reworked to be a separate patch to
simplify review.
This is failing due to some code that isn't built on MSVC
so I didn't catch. Not immediately obvious how to fix this
at first glance, so I'm reverting for now.
Zachary Turner [Wed, 11 Oct 2017 23:33:06 +0000 (23:33 +0000)]
[ADT] Make Twine's copy constructor private.
There's a lot of misuse of Twine scattered around LLVM. This
ranges in severity from benign (returning a Twine from a function
by value that is just a string literal) to pretty sketchy (storing
a Twine by value in a class). While there are some uses for
copying Twines, most of the very compelling ones are confined
to the Twine class implementation itself, and other uses are
either dubious or easily worked around.
This patch makes Twine's copy constructor private, and fixes up
all callsites.
Vedant Kumar [Wed, 11 Oct 2017 21:54:09 +0000 (21:54 +0000)]
[Driver] Export symbols needed to use profile runtime
Apple's API verification tool (tapi) checks that the symbols exported
from a program match a whitelist. When the program uses the profile
runtime, some additional symbols which are typically not part of the
regular whitelist must be exported.
If we're using symbol export directives along with the profile runtime
on Darwin, the driver needs to export the additional symbols to avoid
verification failures.
Alexey Bataev [Wed, 11 Oct 2017 15:29:40 +0000 (15:29 +0000)]
[OPENMP] Fix PR34916: Crash on mixing taskloop|tasks directives.
If both taskloop and task directives are used at the same time in one
program, we may ran into the situation when the particular type for task
directive is reused for taskloop directives. Patch fixes this problem.
projects / clang / log