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++.
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.
projects / clang / log