Douglas Gregor [Fri, 10 Dec 2010 08:57:38 +0000 (08:57 +0000)]
Move the "volatile" bit into QualType's "fast" qualifier set,
increasing the required type alignment from 8 to 16. This provides a
2.5% speedup for -fsyntax-only on a token-cached Cocoa.h, while only
increasing memory consumption in the ASTContext by 0.8%.
John McCall [Fri, 10 Dec 2010 02:59:44 +0000 (02:59 +0000)]
Treat visibility on an enclosing namespace as a non-explicit source of
visibility. Fixes PR8713.
I've disabled a test which was testing that you can #pragma pop visibility
to get out of a namespace's visibility attribute. We should probably just
diagnose that as an error unless it's instrumental to someone's system
headers.
Douglas Gregor [Thu, 9 Dec 2010 23:35:36 +0000 (23:35 +0000)]
Don't crash when code-completing after "#include <". It would be far
better to actually produce a decent set of completions by checking the
system include paths, but not today. Fixes PR8744.
Douglas Gregor [Thu, 9 Dec 2010 21:44:02 +0000 (21:44 +0000)]
Don't walk the translation unit context to produce protocol names when
global code completions are disabled (e.g., because they are
cached). Also, make sure that forward-declared protocols are visited
when we look for all visible names within a declaration context.
Previously, we would end up with duplicate completions for protocols.
Bob Wilson [Thu, 9 Dec 2010 18:58:31 +0000 (18:58 +0000)]
Fix type of last vector operand of Neon quad-register multiple-lane intrinsics.
The sensible thing would be to have these intrinsics take all quad-register
vector operands, but that's not what ARM did. They made the last vector
operand always be a double-register type. Since the lane number
must be a constant, the user can know which half of a quad-register contains
that lane, extract the high or low half of the vector, and adjust the lane
number accordingly. The only advantage I can see for this is that it works
better when you want to multiply a quad-register value by a lane from a
double-register value, but I wouldn't have expected that to be the common
case. Oh well -- at this point we just need to follow the spec.
Bob Wilson [Thu, 9 Dec 2010 18:31:16 +0000 (18:31 +0000)]
Fix the names of the v[r]addhn and v[r]subhn Neon intrinsics.
Their suffixes are supposed to reflect the source operand element type,
not the destination element type. Radar 8746481.
Douglas Gregor [Thu, 9 Dec 2010 16:59:22 +0000 (16:59 +0000)]
When an "inline" declaration was followed by a definition not marked
"inline", we weren't giving the definition weak linkage because the
"inline" bit wasn't propagated. This was a longstanding FIXME that,
somehow, hadn't triggered a bug in the wild. Fix this problem by
tracking whether any declaration was marked "inline", and clean up the
semantics of GNU's "extern inline" semantics calculation based on this
change.
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++.
projects / clang / log