Ben Langmuir [Fri, 30 May 2014 21:20:54 +0000 (21:20 +0000)]
Invalidate the file system cache entries for files that may rebuild
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.
Ben Langmuir [Fri, 30 May 2014 17:42:15 +0000 (17:42 +0000)]
Invalidate the file system cache entries for files that may rebuild
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.
Hans Wennborg [Fri, 30 May 2014 16:59:42 +0000 (16:59 +0000)]
Start adding support for dllimport/dllexport on classes (PR11170)
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.
Tim Northover [Fri, 30 May 2014 14:14:07 +0000 (14:14 +0000)]
AArch64: combine arm64 & aarch64 cases in switch
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.
Aaron Ballman [Fri, 30 May 2014 13:17:17 +0000 (13:17 +0000)]
This test is no longer relevant. It is covered already by [basic.scope.pdecl]p10, and our current test for that is more thorough (though our test is named p9.cpp).
Faisal Vali [Fri, 30 May 2014 04:39:37 +0000 (04:39 +0000)]
Fix 'this' capturing Generic lambdas used within default initializers (PR19876)
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
Adam Nemet [Thu, 29 May 2014 20:47:29 +0000 (20:47 +0000)]
Implement AVX1 vbroadcast intrinsics with vector initializers
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.
Diego Novillo [Thu, 29 May 2014 16:19:27 +0000 (16:19 +0000)]
Fix spurious remarks when -Weverything is used.
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.
Aaron Ballman [Thu, 29 May 2014 12:59:11 +0000 (12:59 +0000)]
Fixing a test case which was failing the MSVC build bots. When -std isn't specified with an MSVC build, it defaults to -std=c++11, which overrides the -x cuda option. In turn, this causes all CUDA language option checks to fail.
This fix is possibly temporary while we determine whether -x cuda should be considered along with -std=c++11 when setting language options.
Richard Smith [Thu, 29 May 2014 03:15:31 +0000 (03:15 +0000)]
When merging functions across modules (and in particular, instantiations of
member functions), ensure that the redecl chain never transitions from 'inline'
to 'not inline', since that violates an AST invariant.
Eli Bendersky [Thu, 29 May 2014 02:35:27 +0000 (02:35 +0000)]
Implement a convenience recursive walk method over a cursor and its descendants.
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).
Alexey Samsonov [Thu, 29 May 2014 01:43:53 +0000 (01:43 +0000)]
[ASan] Hoist blacklisting globals from init-order checking to Clang.
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.
Warren Hunt [Wed, 28 May 2014 19:17:45 +0000 (19:17 +0000)]
Reverting 209503 - Breaks asan blacklists
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.
Adrian Prantl [Wed, 28 May 2014 19:10:59 +0000 (19:10 +0000)]
Debug Info: Fix the source range for IfStmt's ConditionScope.
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
Nick Lewycky [Wed, 28 May 2014 09:56:42 +0000 (09:56 +0000)]
Add 'nonnull' parameter or return attribute when producing an llvm pointer type in a function type where the C++ type is a reference. Update the tests.
Richard Trieu [Wed, 28 May 2014 02:16:01 +0000 (02:16 +0000)]
Move the logic for testing for namespace std into one location. This check can
be performed by using Decl::isInStdNamespace or DeclContext::isStdNamespace
Hans Wennborg [Wed, 28 May 2014 01:52:23 +0000 (01:52 +0000)]
Don't dllimport/export destructor variants implemented by thunks.
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.
Ben Langmuir [Tue, 27 May 2014 19:57:48 +0000 (19:57 +0000)]
Add a test that we don't store stale modtime in modules
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.
James Dennett [Tue, 27 May 2014 19:13:04 +0000 (19:13 +0000)]
Add range accessors for captures of a LambdaExpr.
Summary:
This adds LambdaExpr::captures(), LambdaExpr::explicit_captures()
and LambdaExpr::implicit_captures() as simple wrappers over the underlying
*_begin()/*_end() functions.
Objective-C. Fixes an obscuer crash caused by multiple inclusion of
same framework after complaining about duplicate class definition.
// rdar://17024681
Aaron Ballman [Mon, 26 May 2014 17:03:54 +0000 (17:03 +0000)]
Rejecting the mutable specifier on a freestanding type declaration, instead of supporting it as a "extension" (which serves no purpose). Un-XFAILing the test for mutable specifiers.
Tim Northover [Sat, 24 May 2014 12:51:25 +0000 (12:51 +0000)]
AArch64/ARM64: update Clang after AArch64 removal.
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.
Yaron Keren [Sat, 24 May 2014 07:19:25 +0000 (07:19 +0000)]
CXXInfo memory should be released after calling the destructor
instead of before. The wrong order had no effect since Deallocate()
does nothing right now, but we may replace allocator in the future.
Hans Wennborg [Fri, 23 May 2014 23:29:44 +0000 (23:29 +0000)]
This test doesn't need -O2 -disable-llvm-optzns
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.
Reid Kleckner [Fri, 23 May 2014 21:13:45 +0000 (21:13 +0000)]
Use comdats to avoid double initialization of weak data
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.
Richard Smith [Fri, 23 May 2014 21:00:28 +0000 (21:00 +0000)]
[modules] If a referenced-but-not-instantiated class template specialization
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).
Hans Wennborg [Fri, 23 May 2014 20:37:38 +0000 (20:37 +0000)]
Emit used/dllexport inline method definitions in nested classes (PR19743, PR11170)
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) :-/
Hans Wennborg [Fri, 23 May 2014 20:16:41 +0000 (20:16 +0000)]
Don't suppress warning about dllimport on typedefs etc. in MicrosoftExt mode
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.
projects / clang / log