Fix crash for typedefs for arrays of runtime bounds in Lambdas/Captured Statements, used in sizeof() expression only.

llvm-svn: 258396

Compute and preserve alignment more faithfully in IR-generation.

Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. C

Compute and preserve alignment more faithfully in IR-generation.

Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.

As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.

The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.

Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.

We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.

Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.

ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.

I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.

llvm-svn: 246985

show more ...

Fix assertion failure if a lambda array-capture is followed by a this capture.

llvm-svn: 236043

Test case updates for explicit type parameter to the gep operator

llvm-svn: 232187

Update Clang tests to handle explicitly typed load changes in LLVM.

llvm-svn: 230795

Emit DeferredDeclsToEmit in a DFS order.

Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that.

The advantages of the change are that

* The output order is a bit closer t

Emit DeferredDeclsToEmit in a DFS order.

Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that.

The advantages of the change are that

* The output order is a bit closer to the source order. The change to
test/CodeGenCXX/pod-member-memcpys.cpp is a good example.

* If we decide to deffer more, it will not cause as large changes in the
estcases as it would without this patch.

llvm-svn: 226751

show more ...

Use a CHECK-LABEL. NFC

llvm-svn: 226709

CodeGen: Don't crash when a lambda uses a local constexpr variable

The DeclRefExpr might be for a variable initialized by a constant
expression which hasn't been ODR used.
Emit the initializer for t

CodeGen: Don't crash when a lambda uses a local constexpr variable

The DeclRefExpr might be for a variable initialized by a constant
expression which hasn't been ODR used.
Emit the initializer for the variable instead of trying to capture the
variable itself.

This fixes PR22071.

llvm-svn: 225060

show more ...

CodeGen: Compound literals with funny types shouldn't crash

CodeGen assumed that a compound literal with array type should have a
corresponding LLVM IR array type.

We had two bugs in this area:
- Z

CodeGen: Compound literals with funny types shouldn't crash

CodeGen assumed that a compound literal with array type should have a
corresponding LLVM IR array type.

We had two bugs in this area:
- Zero sized arrays in compound literals would lead to the creation of
an opaque type. This is unnecessary, we should just create an array
type with a bound of zero.
- Funny record types (like unions) lead to exotic IR types for compound
literals. In this case, CodeGen must be prepared to deal with the
possibility that it might not have an array IR type.

This fixes PR21912.

llvm-svn: 224219

show more ...

CHECK-LABEL-ify some code gen tests to improve diagnostic experience when tests fail.

llvm-svn: 188447

Add the 'target-cpu' and 'target-features' attributes to functions.

The back-end will use these values to reconfigure code generation for different
features.

llvm-svn: 175308

Update the tests.

This update coincides with r174110. That change ordered the attributes
alphabetically.

llvm-svn: 174111

Modify the tests for the (sorted) order that the attributes come out as now.

llvm-svn: 173762

Don't assert/crash on reference variables in lambdas bound to a
static local variable from the parent scope. PR14773.

llvm-svn: 171433

clang/test/CodeGenCXX/lambda-expressions.cpp: Relax expression for -Asserts.

"entry:" is not met in -Asserts build.

llvm-svn: 170175

Make sure the __invoke function for lambdas returns properly. Per bug report on IRC>

llvm-svn: 170160

Fix the determination of whether a capture refers to an enclosing
scope when dealing with nested blocks. Fixes <rdar://problem/12778708>.

llvm-svn: 169065

DR1472: A reference isn't odr-used if it has preceding initialization,
initialized by a reference constant expression.

Our odr-use modeling still needs work here: we don't yet implement the 'set of

DR1472: A reference isn't odr-used if it has preceding initialization,
initialized by a reference constant expression.

Our odr-use modeling still needs work here: we don't yet implement the 'set of
potential results of an expression' DR.

llvm-svn: 166361

show more ...

Teach Expr::HasSideEffects about all the Expr types, and fix a bug where it
was mistakenly classifying dynamic_casts which might throw as having no side
effects.

Switch it from a visitor to a switch

Teach Expr::HasSideEffects about all the Expr types, and fix a bug where it
was mistakenly classifying dynamic_casts which might throw as having no side
effects.

Switch it from a visitor to a switch, so it is kept up-to-date as future Expr
nodes are added. Move it from ExprConstant.cpp to Expr.cpp, since it's not
really related to constant expression evaluation.

Since we use HasSideEffect to determine whether to emit an unused global with
internal linkage, this has the effect of suppressing emission of globals in
some cases.

I've left many of the Objective-C cases conservatively assuming that the
expression has side-effects. I'll leave it to someone with better knowledge
of Objective-C than mine to improve them.

llvm-svn: 161388

show more ...

Implement non-internal linkage for lambda closure types that need a
stable mangling, since these lambdas can end up in multiple
translation units. Sema is responsible for deciding when this is the
ca

Implement non-internal linkage for lambda closure types that need a
stable mangling, since these lambdas can end up in multiple
translation units. Sema is responsible for deciding when this is the
case, because it's already responsible for choosing the mangling
number.

llvm-svn: 151029

show more ...

Make sure that we set up the right declaration contexts when creating
and introducing the lambda closure type and its function call
operator. Previously, we assumed that the lambda closure type would

Make sure that we set up the right declaration contexts when creating
and introducing the lambda closure type and its function call
operator. Previously, we assumed that the lambda closure type would
land directly in the current context, and not some parent context (as
occurs with linkage specifications). Thanks to Richard for the test case.

llvm-svn: 150987

show more ...

When we resolve the type of an 'auto' variable, clear out the linkage
of that variable; it will need to be recomputed with the resolved
type.

llvm-svn: 150984

Basic support for name mangling of C++11 lambda expressions. Because
name mangling in the Itanium C++ ABI for lambda expressions is so
dependent on context, we encode the number used to encode each l

Basic support for name mangling of C++11 lambda expressions. Because
name mangling in the Itanium C++ ABI for lambda expressions is so
dependent on context, we encode the number used to encode each lambda
as part of the lambda closure type, and maintain this value within
Sema.

Note that there are a several pieces still missing:
- We still get the linkage of lambda expressions wrong
- We aren't properly numbering or mangling lambda expressions that
occur in default function arguments or in data member initializers.
- We aren't (de-)serializing the lambda numbering tables

llvm-svn: 150982

show more ...

Rework the Sema/AST/IRgen dance for the lambda closure type's
conversion to function pointer. Rather than having IRgen synthesize
the body of this function, we instead introduce a static member
funct

Rework the Sema/AST/IRgen dance for the lambda closure type's
conversion to function pointer. Rather than having IRgen synthesize
the body of this function, we instead introduce a static member
function "__invoke" with the same signature as the lambda's
operator() in the AST. Sema then generates a body for the conversion
to function pointer which simply returns the address of __invoke. This
approach makes it easier to evaluate a call to the conversion function
as a constant, makes the linkage of the __invoke function follow the
normal rules for member functions, and may make life easier down the
road if we ever want to constexpr'ify some of lambdas.

Note that IR generation is responsible for filling in the body of
__invoke (Sema just adds a dummy body), because the body can't
generally be expressed in C++.

Eli, please review!

llvm-svn: 150783

show more ...

Add a coverage test for lambda expression IRGen.

llvm-svn: 150458