They were causing CodeGenCXX/mangle-exprs.cpp to fail.
Revert "Remove the circular reference to LambdaExpr in CXXRecordDecl."
Revert "Again: Teach TreeTransform and family how to transform generic lambdas nested within templates and themselves."
llvm-svn: 193226
Both Doug and Richard had asked me to remove the circular reference in CXXRecordDecl to LambdaExpr by factoring out and storing the needed information from LambdaExpr directly into CXXRecordDecl.
No change in functionality.
In addition, I have added an IsGenericLambda flag - this makes life a little easier when we implement capturing, and are Sema-analyzing the body of a lambda (and the calloperator hasn't been wired to the closure class yet). Any inner lambdas can have potential captures that could require walking up the scope chain and checking if any generic lambdas are capture-ready. This 'bit' makes some of that checking easier.
This patch was approved by Doug with minor modifications (comments were cleaned up, and all data members were converted from bool/enum to unsigned, as requested):
http://llvm-reviews.chandlerc.com/D1856
Thanks!
llvm-svn: 193223
The C++ compiler used to build prepare-builtins
may differ from the llvm/clang for which we are
building libclc.
Use 'clang++' as the default compiler.
Patch by: Jeroen Ketema
llvm-svn: 193220
modules.
With this fixed, I no longer see any test regressions in the libc++ test suite
when enabling a single-module module.map for libc++ (other than issues with my
system headers).
llvm-svn: 193219
This check was overly strict. Relax it.
While one could conceivably want nested one-lining:
(Foo) aFoo = (x = 1, y = (t = 3, q = “Hello), z = 3.14)
the spirit of this feature is mostly to make *SMALL LINEAR* structs come out more compact.
Aggregates with children and no summary for now just disable the one-lining. Define a one-liner summary to override :)
llvm-svn: 193218
lambdas nested within templates and themselves.
A previous attempt http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130930/090049.html resulted in PR 17476, and was reverted,
The original TransformLambdaExpr (pre generic-lambdas) transformed the TypeSourceInfo of the Call operator in its own instantiation scope via TransformType. This resulted in the parameters of the call operator being mapped to their transformed counterparts in an instantiation scope that would get popped off.
Then a call to TransformFunctionParameters would add the parameters and their transformed mappings (but newly created ones!) to the current instantiation scope. This would result in a disconnect between the new call operator's TSI parameters and those used to construct the call operator declaration. This was ok in the non-generic lambda world - but would cause issues with nested transformations (when non-generic and generics were interleaved) in the generic lambda world - that I somewhat kludged around initially - but this resulted in PR17476.
The new approach seems cleaner. We only do the transformation of the TypeSourceInfo - but we make sure to do it in the current instantiation scope so we don't lose the untransformed to transformed mappings of the ParmVarDecls when they get created.
This does not yet include capturing.
Please see test file for examples.
This patch was LGTM'd by Doug:
http://llvm-reviews.chandlerc.com/D1784
llvm-svn: 193216
The SelectionDAGBuilder was promoting vector kernel arguments to legal
types, but this won't work for R600 and SI since kernel arguments are
stored in memory and can't be promoted. In order to handle vector
arguments correctly we need to look at the original types from the LLVM IR
function.
llvm-svn: 193215
For some targets, it is useful to be able to look at the original
type of an argument without having to dig through the original IR.
This also fixes a bug in SelectionDAGBuilder where InputArg.PartOffset
was not taking into account the offset of structure elements.
Patch by: Justin Holewinski
Tom Stellard:
- Changed the type of ArgVT to EVT, so it can store non-simple types
like v3i32.
llvm-svn: 193214
This patch won't change LLD's behavior because it's a temporary file and
LLD does not use the file extension to determine file type. But using the
correct file extension is a good thing.
llvm-svn: 193211
With this extension, friend function declarations will retain the language
linkage specified for previous declarations instead of emitting an error
diagnostic.
The feature is known to be compatible with GCC and MSVC and permits a
language to be specified indirectly where it cannot otherwise be written
directly in class scope.
Work is ongoing to improve linkage spec diagnostics.
Fixes PR17337.
Reviewed by Richard Smith.
llvm-svn: 193206
check using the ubsan runtime) and -fsanitize=local-bounds (for the middle-end
check which inserts traps).
Remove -fsanitize=local-bounds from -fsanitize=undefined. It does not produce
useful diagnostics and has false positives (PR17635), and is not a good
compromise position between UBSan's checks and ASan's checks.
Map -fbounds-checking to -fsanitize=local-bounds to restore Clang's historical
behavior for that flag.
llvm-svn: 193205
We would not identify pointer-to-member construction in a non-type
template argument if it was either a FieldDecl or a CXXMethodDecl.
However, this would incorrectly reject declarations that were injected
via an IndirectFieldDecl (e.g. a field inside of an anonymous union).
This fixes PR17657.
llvm-svn: 193203
This fixes pr17624.
A FIXME from Richard Smith:
It seems to me that the root cause is that a per-Decl 'used' flag doesn't
really make much sense in the way we use it now. I think we should either track
whether that particular declaration is used (with isUsed scanning the entire
redecl chain), or we should only have one flag for the entire redeclaration
chain (perhaps by always looking at the flag on either the most recent decl or
the canonical decl). Modeling it as "is this declaration or any previous
declaration used" is weird, and requires contortions like the loop at the end
of Sema::MarkFunctionReferenced.
llvm-svn: 193202
This fixes pr17639.
Before this patch clang would consider
void foo(void) __attribute((alias("__foo")));
a declaration. It now correctly handles it as a definition.
Initial patch by Alp Toker. I added support for variables.
llvm-svn: 193200
Remove unnecessary creation of LexicalScope in collectDeadVariables.
The created LexicialScope was only used to get isAbstractScope, which
should be false from the creation:
"new LexicalScope(NULL, DIDescriptor(SP), NULL, false);".
We can also remove a DenseMap that holds the created LexicalScopes.
llvm-svn: 193196
/manifestfile:<path> specifies an alternative manifest file output path.
Default is "<output-path>.manifest" where <output-path> is the executable's
path.
llvm-svn: 193195
Since (as of r190716) Clang no longer emits debug info for C++ friend
declarations (and it seems GCC never has/does, which was the motivation
for the Clang change), there's no actual reachable case for implementing
the part of DWARF 4, Section 7.27 part 5 that pertains to friends.
Leave an assert here so that if/when we do have a client producing
friends and using type units, we can fill in the gap and add appropriate
(unit and feature) tests.
llvm-svn: 193193
This is a fixed version of r193161. In order to handle
void foo() __attribute__((alias("bar")));
void bar() {}
void zed() __attribute__((alias("foo")));
it is not enough to delay aliases to the end of the TU, we have to do two
passes over them to find if they are defined or not.
This can be implemented by producing alias as we go and just doing the second
pass at the end. This has the advantage that other parts of clang that were
expecting alias to be processed in order don't have to be changed.
This patch also handles cyclic aliases.
llvm-svn: 193188
The set of circumstances where the writeback register is allowed to be in the
list of registers is rather baroque, but I think this implements them all on
the assembly parsing side.
For disassembly, we still warn about an ARM-mode LDM even if the architecture
revision is < v7 (the required architecture information isn't available). It's
a silly instruction anyway, so hopefully no-one will mind.
rdar://problem/15223374
llvm-svn: 193185
Some of the shared compiler/linker flags start with -m, so they've been
getting passed to the compiler only since r180073. Now, the -m* wildcard
is processed after the shared flags and the ignored flags.
Found by Laszlo Nagy!
llvm-svn: 193184
The AMDGPUIndirectAddressing pass was previously responsible for
lowering private loads and stores to indirect addressing instructions.
However, this pass was buggy and way too complicated. The only
advantage it had over the new simplified code was that it saved one
instruction per direct write to private memory. This optimization
likely has a minimal impact on performance, and we may be able
to duplicate it using some other transformation.
For the private address space, we now:
1. Lower private loads/store to Register(Load|Store) instructions
2. Reserve part of the register file as 'private memory'
3. After regalloc lower the Register(Load|Store) instructions to
MOV instructions that use indirect addressing.
llvm-svn: 193179
Includes a test case/FIXME demonstrating a bug/limitation in pointer to
member hashing. To be honest I'm not sure why we don't just always use
summary hashing for referenced types... but perhaps I'm missing
something.
llvm-svn: 193175
This patch wasn't reviewed, and isn't correctly preserving the behaviors
relied upon by QT. I don't have a direct example of fallout, but it
should go through the standard code review process. For example, it
should never have removed the QT test case that was added when fixing
those users.
llvm-svn: 193174
Rafael Espindola