Before determining the effect the alignment of base struct will have in the aligment of the sub-struct,
take into account if the sub-struct is packed and its maximum field alignment.
Douglas Gregor [Thu, 9 Dec 2010 00:06:27 +0000 (00:06 +0000)]
A typename specifier can end up referring to a unresolved using
declaration that is a value in ill-formed code. Instead of crashing,
treat this as a dependent typename specifier and suggest that the
using add "typename" into the using declaration. Fixes <rdar://problem/8740998>.
Bob Wilson [Wed, 8 Dec 2010 22:37:56 +0000 (22:37 +0000)]
Stop using builtins for the "_lane" variants of saturating multiply intrinsics.
Remove the "splat" parameter from the EmitNeonCall function, since it is no
longer needed.
Jay Foad [Tue, 7 Dec 2010 08:25:34 +0000 (08:25 +0000)]
PR5207: Change APInt methods trunc(), sext(), zext(), sextOrTrunc() and
zextOrTrunc(), and APSInt methods extend(), extOrTrunc() and new method
trunc(), to be const and to return a new value instead of modifying the
object in place.
John McCall [Tue, 7 Dec 2010 00:47:33 +0000 (00:47 +0000)]
Kill FullExpr, as it was not, in fact, used anywhere in the code base.
I'm not opposed to the idea in concept, but there's no point in preserving
abortive experiments.
Douglas Gregor [Mon, 6 Dec 2010 22:09:19 +0000 (22:09 +0000)]
Objective-C pointer conversions to 'id' or qualified 'id' subsume
cv-qualification conversions. More specifically, there's an implicit
cv-qualification conversion (even one that drops qualifiers) when
converting to 'id' or qualified 'id'. Fixes <rdar://problem/8734046>.
John McCall [Mon, 6 Dec 2010 20:48:59 +0000 (20:48 +0000)]
Split out a function to do lvalue conversion on objects; this is basically
FunctionArrayLvalueConversion but without the function/array decay. Generally
this is only appropriate for use sites that know the type of the expression
and thus that it can't be subject to the decays.
Also make sure we do lvalue-to-rvalue on the bases of ivar references.
Douglas Gregor [Mon, 6 Dec 2010 18:36:25 +0000 (18:36 +0000)]
Re-implement caching for the linkage calculation of declarations.
My previous attempt at solving the compile-time problem with many
redeclarations of the same entity cached both linkage and visibility,
while this patch only tackles linkage. There are several reasons for
this difference:
- Linkage is a language concept, and is evaluated many times during
semantic analysis and codegen, while visibility is only a
code-generation concept that is evaluated only once per (unique)
declaration. Hence, we *must* optimize linkage calculations but
don't need to optimize visibility computation.
- Once we know the linkage of a declaration, subsequent
redeclarations can't change that linkage. Hence, cache
invalidation is far simpler than for visibility, where a later
redeclaration can completely change the visibility.
- We have 3 spare bits in Decl to store the linkage cache, so the
cache doesn't increase the size of declarations. With the
visibility+linkage cache, NamedDecl got larger.
Douglas Gregor [Mon, 6 Dec 2010 17:49:01 +0000 (17:49 +0000)]
Revert r120808, my previous implementation of caching for the linkage
and visibility of declarations, because it was extremely messy and it
increased the size of NamedDecl.
Un-templatetize this method. It's definition is out of line in the .cpp file,
so that's not a valid thing to do at all. Instead, switch to a ValueDecl
argument, the template isn't really necessary here.
When handling the types explicitly in the code, it becomes awkward to cerate
the CXXBaseOrMemberInitializer object in so many places. Re-flow the code to
calculate the Init expression first, and then create the initializer. If this
is too gross, we can factor the init expression logic into helper functions,
but it's not past my threshold yet.
John McCall [Mon, 6 Dec 2010 08:20:24 +0000 (08:20 +0000)]
Rename CXXExprWithTemporaries -> ExprWithCleanups; there's no theoretical
reason this is limited to C++, and it's certainly not limited to temporaries.
John McCall [Mon, 6 Dec 2010 06:10:02 +0000 (06:10 +0000)]
__block variables require us to evaluate the RHS of an assignment before
the LHS, or else the pointer might be invalid. This is kindof dumb, but
go ahead and make sure we're doing that for l-value scalar assignment,
which fixes a miscompile of obj-c++.dg/block-seq.mm.
Leave a FIXME for how to solve this problem for agg __blocks.
John McCall [Mon, 6 Dec 2010 05:26:58 +0000 (05:26 +0000)]
Clarify the logic for when to build an overloaded binop. In particular,
build one when either of the operands calls itself type-dependent;
previously we were building when one of the operand types was dependent,
which is not always the same thing and which can lead to unfortunate
inconsistencies later. Fixes PR8739.
John McCall [Sun, 5 Dec 2010 02:00:02 +0000 (02:00 +0000)]
Fix a bug in the emission of __real/__imag l-values on scalar operands.
Fix a bug in the emission of complex compound assignment l-values.
Introduce a method to emit an expression whose value isn't relevant.
Make that method evaluate its operand as an l-value if it is one.
Fixes our volatile compliance in C++.
John McCall [Sat, 4 Dec 2010 08:14:53 +0000 (08:14 +0000)]
Remove some defensive calls to EmitLoadOfPropertyRefLValue that shouldn't
be required, and then fix up some missing loads on overloaded-operator
paths which that exposed.
John McCall [Sat, 4 Dec 2010 03:47:34 +0000 (03:47 +0000)]
Although we currently have explicit lvalue-to-rvalue conversions, they're
not actually frequently used, because ImpCastExprToType only creates a node
if the types differ. So explicitly create an ICE in the lvalue-to-rvalue
conversion code in DefaultFunctionArrayLvalueConversion() as well as several
other new places, and consistently deal with the consequences throughout the
compiler.
In addition, introduce a new cast kind for loading an ObjCProperty l-value,
and make sure we emit those nodes whenever an ObjCProperty l-value appears
that's not on the LHS of an assignment operator.
This breaks a couple of rewriter tests, which I've x-failed until future
development occurs on the rewriter.
Ted Kremenek kindly contributed the analyzer workarounds in this patch.
Introduce CompilerInvocation::setLangDefaults function
This patch refactors the CompilerInvocation code to introduce a
CompilerInvocation::setLangDefaults function, which can set up a
LangOptions with the defaults for a given language and language
standard. This function is useful for non-command line based Clang
clients which need to set up a CompilerInvocation manually for a
specific language.
Bob Wilson [Fri, 3 Dec 2010 17:50:54 +0000 (17:50 +0000)]
Add missing vext_f32 and vextq_f32 Neon intrinsics (Radar 8592601).
For some reason these were not included in the list of Neon intrinsics in
ARM's documentation, so they didn't make it into Clang either.
Douglas Gregor [Fri, 3 Dec 2010 17:11:42 +0000 (17:11 +0000)]
Implement caching for the linkage and visibility calculations of
declarations.
The motivation for this patch is that linkage/visibility computations
are linear in the number of redeclarations of an entity, and we've run
into a case where a single translation unit has > 6500 redeclarations
of the same (unused!) external variable. Since each redeclaration
involves a linkage check, the resulting quadratic behavior makes Clang
slow to a crawl. With this change, a simple test with 512
redeclarations of a variable syntax-checks ~20x faster than
before.
That said, I hate this change, and will probably end up reverting it
in a few hours. Reasons to hate it:
- It makes NamedDecl larger, since we don't have enough free bits in
Decl to squeeze in the extra information about caching.
- There are way too many places where we need to invalidate this
cache, because the visibility of a declaration can change due to
redeclarations (!). Despite self-hosting and passing the testsuite,
I have no confidence that I've found all of places where this cache
needs to be invalidated.
projects / clang / log