I was bitten by this when working with the dll attributes: when a dll
attribute was cloned from a class template declaration to its
specialization, the Inherited flag didn't get cloned.
Differential Revision: http://reviews.llvm.org/D3972
llvm-svn: 209950
This reapplies r209910 with a fix for the assertion failures hit on the
buildbots.
original commit message:
I thought we could get away without this, but it means that the
FileEntry objects actually refer to the wrong files, since pcms are not
updated inplace, they are atomically renamed into place after compiling
a module.
So we are close to the original behaviour of invalidating the cache for
all modules being removed, but now we should only invalidate the ones
that depend on whichever module failed to load.
Unfortunately I haven't come up with a new test that didn't require
a race between parallel invocations of clang.
<rdar://problem/17038180>
llvm-svn: 209922
I thought we could get away without this, but it means that the
FileEntry objects actually refer to the wrong files, since pcms are not
updated inplace, they are atomically renamed into place after compiling
a module.
So we are close to the original behaviour of invalidating the cache for
all modules being removed, but now we should only invalidate the ones
that depend on whichever module failed to load.
Unfortunately I haven't come up with a new test that didn't require
a race between parallel invocations of clang.
<rdar://problem/17038180>
llvm-svn: 209910
This implements the central part of support for dllimport/dllexport on
classes: allowing the attribute on class declarations, inheriting it
to class members, and forcing emission of exported members. It's based
on Nico Rieck's patch from http://reviews.llvm.org/D1099.
This patch doesn't propagate dllexport to bases that are template
specializations, which is an interesting problem. It also doesn't
look at the rules when redeclaring classes with different attributes,
I'd like to do that separately.
Differential Revision: http://reviews.llvm.org/D3877
llvm-svn: 209908
There shouldn't be any difference in behaviour here, at least not in
any configurations people care about and possibly not in any reachable
configurations.
llvm-svn: 209899
http://llvm.org/bugs/show_bug.cgi?id=19876
The following C++1y code results in a crash:
struct X {
int m = 10;
int n = [this](auto) { return m; }(20);
};
When implicitly instantiating the generic lambda's call operator specialization body, Sema is unable to determine the current 'this' type when transforming the MemberExpr 'm' - since it looks for the nearest enclosing FunctionDeclDC - which is obviously null.
I considered two ways to fix this:
1) In InstantiateFunctionDefinition, when the context is saved after the lambda scope info is created, retain the 'this' pointer.
2) Teach getCurrentThisType() to recognize it is within a generic lambda within an NSDMI/default-initializer and return the appropriate this type.
I chose to implement #2 (though I confess I do not have a compelling reason for choosing it over #1).
Richard Smith accepted the patch:
http://reviews.llvm.org/D3935
Thank you!
llvm-svn: 209874
These intrinsics are special because they directly take a memory operand (AVX2
adds the register counterparts). Typically, other non-memop intrinsics take
registers and then it's left to isel to fold memory operands.
In order to LICM intrinsics directly reading memory, we require that no stores
are in the loop (LICM) or that the folded load accesses constant memory
(MachineLICM). When neither is the case we fail to hoist a loop-invariant
broadcast.
We can work around this limitation if we expose the load as a regular load and
then just implement the broadcast using the vector initializer syntax. This
exposes the load to LICM and other optimizations.
At the IR level this is translated into a series of insertelements. The
sequence is already recognized as a broadcast so there is no impact on the
quality of codegen.
_mm256_broadcast_pd and _mm256_broadcast_ps are not updated by this patch
because right now we lack the DAG-combiner smartness to recover the broadcast
instructions. This will be tackled in a follow-on.
There will be completing changes on the LLVM side to remove the LLVM
intrinsics and to auto-upgrade bitcode files.
Fixes <rdar://problem/16494520>
llvm-svn: 209846
Summary:
This adds documentation for -Rpass, -Rpass-missed and -Rpass-analysis.
It also adds release notes for 3.5.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3730
llvm-svn: 209841
Summary:
These two flags are in the same family as -Rpass, but are used in
different situations.
-Rpass-missed is used by optimizers to inform the user when they tried
to apply an optimization but couldn't (or wouldn't).
-Rpass-analysis is used by optimizers to report analysis results back
to the user (e.g., why the transformation could not be applied).
Depends on D3682.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3683
llvm-svn: 209839
With -Weverything, the backend remarks are enabled. This was
causing spurious diagnostics for remarks that we don't yet
handle (cf http://reviews.llvm.org/D3683).
This will stop being a problem once http://reviews.llvm.org/D3683
is committed.
llvm-svn: 209823
This fix is possibly temporary while we determine whether -x cuda should be considered along with -std=c++11 when setting language options.
llvm-svn: 209808
member functions), ensure that the redecl chain never transitions from 'inline'
to 'not inline', since that violates an AST invariant.
llvm-svn: 209794
Before r160106 there was a way to recursively visit all descendants of a cursor
via Cursor_visit, but it was removed. Since then, every user needs to
reimplement the recursive descent into get_children.
Adding a walk_preorder() method to Cursor that conveniently implements recursive
walking in a Pythonic way. This also greatly simplifies get_cursor and
get_cursors in tests/cindex/util.py (walk_preorder is now tested through these
utility functions, since they are used in many tests).
llvm-svn: 209793
Clang knows about the sanitizer blacklist and it makes no sense to
add global to the list of llvm.asan.dynamically_initialized_globals if it
will be blacklisted in the instrumentation pass anyway. Instead, we should
do as much blacklisting as possible (if not all) in the frontend.
llvm-svn: 209789
Until now all CUDA-specific attributes were represented with
CXCursor_UnexposedAttr; now they are actually implemented, including the Python
bindings.
llvm-svn: 209767
I opened a discussion on cfe-commits. Ideally we've got a few things
that need to happen. CompilerRT should probably have blacklists tests.
Asan should probably not depend on that specific field.
llvm-svn: 209766
Since the continuation block of the if statement is emitted within the
condition scope this had the undesirable effect of creating a line table
entry at the end of the then or else statement, a line that may have never
been executed.
PR19864 / rdar://problem/17052973
llvm-svn: 209764
These note diags have the same message and can be unified further but for now
let's just bring them together.
Incidental change: Display a source range in the final attr diagnostic.
llvm-svn: 209728
Before (with just the right line length:
switch (a) {
case some_namespace::some_constant
:
return;
}
After:
switch (a) {
case some_namespace::
some_constant:
return;
}
llvm-svn: 209725
MSVC doesn't export these functions, so trying to import them doesnt' work.
Also, don't let any dll attributes on the CXXDestructorDecl influence the
thunk's linkage -- they should always be linkonce_odr.
This takes care of the FIXME's for this in Nico's tests.
Differential Revision: http://reviews.llvm.org/D3930
llvm-svn: 209706
The change from r209195 turned out to be important to avoid saving stale
modification time/expected size information in a module file when there
are 3 or more modules in a dependency chain and the bottom one is
rebuilt. So add a test for that.
rdar://problem/17038180
llvm-svn: 209682
Summary:
This adds LambdaExpr::captures(), LambdaExpr::explicit_captures()
and LambdaExpr::implicit_captures() as simple wrappers over the underlying
*_begin()/*_end() functions.
Reviewers: aaron.ballman
Differential Revision: http://reviews.llvm.org/D3926
llvm-svn: 209679
That small change, although it looked harmless, it made emitting the LValue
on the PHI node without the proper cast. Reverting it fixes PR19841.
llvm-svn: 209663
A few (mostly CodeGen) parts of Clang were tightly coupled to the
AArch64 backend. Now that it's gone, they will not even compile.
I've also deduplicated RUN lines in many of the AArch64 tests. This
might improve "make check-all" time noticably: some of those NEON
tests were monsters.
llvm-svn: 209578
instead of before. The wrong order had no effect since Deallocate()
does nothing right now, but we may replace allocator in the future.
llvm-svn: 209567
I forgot to fix this one in r209145. We use these flags on dllimport tests
to make sure we emit code for available_externaly functions and don't inline
the IR.
llvm-svn: 209564
Initializers of global data that can appear multiple TUs (static data
members of class templates or __declspec(selectany) data) are now in a
comdat group keyed on the global variable being initialized. On
non-Windows platforms, this is a code size and startup time
optimization. On Windows, this is necessary for ABI compatibility with
MSVC.
Fixes PR16959.
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D3811
llvm-svn: 209555
gets explicitly specialized, don't reuse the previous class template
specialization declaration as a new declaration. The benefit here is fairly
marginal, it harms source fidelity, and this is horrible to model if the
specialization was imported from another module (without this change, it
asserts or worse).
llvm-svn: 209552
The previous code that was supposed to handle this didn't work
since parsing of inline method definitions is delayed to the end
of the outer class definition. Thus, when HandleTagDeclDefinition()
got called for the inner class, the inline functions in that class
had not been parsed yet.
Richard suggested that the way to do this is by handling inline
method definitions through a new ASTConsumer callback.
I really wanted to call ASTContext::DeclMustBeEmitted() instead of
checking for attributes, but doing that causes us to compute linkage,
and then we fail with "error: unsupported: typedef changes linkage
of anonymous type, but linkage was already computed" on tests like
this: (from SemaCXX/undefined-internal.cpp) :-/
namespace test7 {
typedef struct {
void bar();
void foo() { bar(); }
} A;
}
Differential Revision: http://reviews.llvm.org/D3809
llvm-svn: 209549
It's true the MSVC doesn't warn about dllimport when applied to e.g. a typedef,
but that applies to dllexport too. I'd like us to be consistent, and I think
the right thing to do is to warn.
The original test that came with implementing the old behaviour doesn't provide
a good motivation, and it said it was checking that we're not repoting an *error*,
which is still true since this is just a warning.
There are plenty of tests e.g. in Sema/dllimport.c to check that we do warn
about dllimport on non functions or variables.
Differential Revision: http://reviews.llvm.org/D3832
llvm-svn: 209546
If we lookup a path using its 'real' path first, we need to ensure that
when we run header search we still use the VFS-mapped path or we will
not be able to find the corresponding module for the header.
The real problem is that we tie the name of a file to its underlying
FileEntry, which is uniqued by inode, so we only ever get the first name
it is looked up by. This doesn't work with modules, which rely on a
specific file system structure. I'm hoping to have time to write up a
proposal for fixing this more permanently soon, but as a stopgap this
patch updates the name of the file's directory if it comes from a VFS
mapping.
llvm-svn: 209534
This change is a precondition to the proposed change to handle temporary
dtors correctly.
The idea is to explicitly search for the next return that doesn't have other
paths into it (that is, if the current block is dead, the block containing the
return must be dead, too). Thus, introducing non-control-flow block
transitions will not break the logic.
llvm-svn: 209531
As Jordan noted, it makes more sense when we store it in the ParentMap,
and doesn't really make a difference when we return it from getParents.
llvm-svn: 209530
Enables the emission of MS-compatible RTTI data structures for use with
typeid, dynamic_cast and exceptions. Does not implement dynamic_cast
or exceptions. As an artiface, typeid works in some cases but proper
support an testing will coming in a subsequent patch.
majnemer has fuzzed the results. Test cases included.
Differential Revision: http://reviews.llvm.org/D3833
llvm-svn: 209523
This patch implements support for selectively disabling optimizations on a
range of function definitions through a pragma. The implementation is that
all function definitions in the range are decorated with attribute
'optnone'.
#pragma clang optimize off
// All function definitions in here are decorated with 'optnone'.
#pragma clang optimize on
// Compilation resumes as normal.
llvm-svn: 209510
Summary:
Previously, you could not specify the original file name when passing a preprocessed file into the compiler
Now you can use 'clang -Xclang -main-file-name -Xclang <original file name> ...'
Or 'clang -cc1 -main-file-name <original file name> ...'
llvm-svn: 209503
The last step of _mm_cvtps_pi16 should use _mm_packs_pi32, which is a function
that reads two __m64 values and packs four 32-bit values into four 16-bit
values.
<rdar://problem/16873717>
llvm-svn: 209489
This was fairly broken. For example,
@__dso_handle would or would not get an unnamed_addr depending on how many
global destructors were used in a translation unit.
The consensus was that not every runtime variable is unnamed_addr and that
__dso_handle handle should not be, so just don't add unnamed_addr in
CreateRuntimeVariable.
llvm-svn: 209484
Call it "libclang_rt.builtins-<arch>.a" to be consistent
with sanitizers/profile libraries naming. Modify Makefile
and CMake build systems and Clang driver accordingly.
Fixes PR19822.
llvm-svn: 209474
instantiated in another module, and the instantiation uses a partial
specialization, include the partial specialization and its template arguments
in the update record. We'll need them if someone imports the second module and
tries to instantiate a member of the template.
llvm-svn: 209472
Summary:
The limits on the number of fix-it hints and ranges attached to a
diagnostic are arbitrary and don't apply universally to all users of the
DiagnosticsEngine. The way the limits are enforced may lead to diagnostics
generating invalid sets of fixes. I suggest removing the limits, which will also
simplify the implementation.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D3879
llvm-svn: 209468
And "none" pseudo-style indicating that formatting should be not
applied.
(1) Using .clang-format with "DisableFormat: true" effectively prevents
formatting for all files within the folder containing such .clang-format
file.
(2) Using -fallback-style=none together with -style=file prevents
formatting when .clang-format is not found, which can be used in on-save
callback.
Patch by Adam Strzelecki. Thank you!
llvm-svn: 209446
Before:
template <int> struct A4 { A4() { }
};
After:
template <int i> struct A4 {
A4() {}
};
This fixes llvm.org/PR19813 (at least the part that isn't working as
intended).
llvm-svn: 209438
This brings "-arch armv7m" (etc) behaviour more in line with what's expected
for developers on OS X, and allows Clang to find an "ld" (for example) in the
same directory instead of using the default /usr/bin/ld.
Unfortunately no test because it relies on the specific place Clang is running
from.
rdar://problem/16427320
llvm-svn: 209437
As the memory ownership is handled by the SpecificBumpPtrAllocator
anyway, there is no need to duplicate states when inserting them into
the Seen-set. This leads to an improvement of ~10% on the benchmark
formatting file.
No functional changes intended.
llvm-svn: 209422
Before:
var literal = 'hello ' + 'world';
After:
var literal = 'hello ' +
'world';
There is no reason to concatenated two string literals with a '+' unless
the line break is intended.
llvm-svn: 209413
Before:
int i{a *b};
After:
int i{a * b};
Also fix unrelated issue where braced init lists were counted as blocks
and prevented single-line functions.
llvm-svn: 209412
It also adds a simple initial version of codegen for pragma omp simd (it will change in the future to support all the clauses).
Differential revision: http://reviews.llvm.org/D3644
llvm-svn: 209411
If simple (one-statement) blocks can be inlined, the length needs to be
calculated correctly.
Before (in JavaScript but this also affects lambdas, etc.):
var x = {
valueOf: function() { return 1; }
};
After:
var x = {valueOf: function() { return 1; }};
llvm-svn: 209410
ASTReaderListener's documentation states that visitInputFile will be
called based on the return values of needsInputFileVisitation and
needsSystemInputFileVisitation, but ChainedASTReaderListener may call
these methods on a child listener based on the values returned by the
other child.
Even worse, the calls to visitInputFile may be short-circuited due to
the use of the boolean or, so the calls to visit may not occur at all
for the second listener.
This updates ChainedASTReaderListener::visitInputFile to propagate the
ASTReaderListener behaviour to both children.
llvm-svn: 209394
There are a couple of issues with writing VFS maps that are awkward to
fix within the current mutually recursive approach. Instead, replace
the algorithm with an iterative version that uses an explicit stack of
directories.
Includes tests for cases the old approach was tripping on.
llvm-svn: 209332
Summary:
Naming the destructor using a typedef-name for the class-name is
well-formed.
This fixes PR19620.
Reviewers: rsmith, doug.gregor
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3583
llvm-svn: 209319
On test files I ran this on, memory consumption overall went down from
2.5G to 2G, without performance regressions.
I also investigated making DynTypedNode by itself smaller (by pulling
out pointers for everything that doesn't fit in 8 bytes). This led to
another 200-300MB saved, but also introduced a significant regression in
performance due to the memory management overhead.
llvm-svn: 209297
Eliminate createMainFileID() / createMainFileIDForMemBuffer() utility
functions. These didn't add much convenience and conflated two distinct
operations.
This change makes things easier to follow by providing a consistent interface
and getting rid of a bunch of cast-to-voids.
llvm-svn: 209266
Checking if a path starts with another path isn't sufficient for
determining if one is contained within the heirarchy of the other.
We need to ensure that the substring ends at a directory boundary.
llvm-svn: 209250
This moves the logic to write a JSON VFS mapping from the C api into
VirtualFileSystem, so that we can use it internally.
No functional change.
llvm-svn: 209241
This is a testcase for r209227, a change in LLVM that automatically sets
visibility to default when the linkage is changed to local (rather than
asserting).
What this testcase triggers is hard to reproduce otherwise: the
`GlobalValue` is created (with non-local linkage), the visibility is set
to hidden, and then the linkage is set to local.
PR19760
llvm-svn: 209228
This is a GNU attribute that causes calls within the attributed function
to be inlined where possible. It is implemented by giving such calls the
alwaysinline attribute.
Differential Revision: http://reviews.llvm.org/D3816
llvm-svn: 209217
Hans Wennborg