| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
reason this is limited to C++, and it's certainly not limited to temporaries.
llvm-svn: 120996
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 120992
|
|
|
|
|
|
|
|
|
| |
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++.
llvm-svn: 120931
|
|
|
|
|
|
|
| |
be required, and then fix up some missing loads on overloaded-operator
paths which that exposed.
llvm-svn: 120896
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 120890
|
|
|
|
|
|
| |
the l-value.
llvm-svn: 120884
|
|
|
|
|
|
|
|
| |
ObjCPropertyRefExpr
into the latter.
llvm-svn: 120643
|
|
|
|
|
|
|
| |
case based on CodeGen/volatile-1.c which tests the current C++
semantics, and note the many, many places we fall short of them.
llvm-svn: 119402
|
|
|
|
|
|
|
|
|
| |
assignment to volatiles in C. This in effect reverts some of mjs's
work in and around r72572. Basically, the C++ standard is quite
clear, except that it lies about volatile behavior approximating
C's, whereas the C standard is almost actively misleading.
llvm-svn: 119344
|
|
|
|
|
|
| |
a compound assignment is always already in the computation type.
llvm-svn: 119330
|
|
|
|
|
|
|
|
| |
Return the result of a complex assignment with the original values,
not by performing a load from the l-value; this is the correct
semantics in C, although not in C++.
llvm-svn: 119037
|
|
|
|
|
|
|
|
|
|
| |
implicit conversions; the last batch was specific to promotions.
I think this is the full set we need. I do think dividing the cast
kinds into floating and integral is probably a good idea.
Annotate a *lot* more C casts with useful cast kinds.
llvm-svn: 119036
|
|
|
|
|
|
| |
between complex types.
llvm-svn: 118994
|
|
|
|
|
|
| |
complex conditionals. Radar 8453812.
llvm-svn: 114376
|
|
|
|
|
|
| |
to the new constants.
llvm-svn: 112047
|
|
|
|
| |
llvm-svn: 108363
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(e.g., a call, cast, etc.), immediately adjust the expression's type
to strip cv-qualifiers off of all non-class types (in C++) or all
types (in C). This effectively extends my previous fix for PR7463,
which was restricted to calls, to other kinds of expressions within
similar characteristics. I've audited every use of
getNonReferenceType() in the code base, switching to the newly-renamed
getNonLValueExprType() where necessary.
Big thanks to Eli for pointing out just how incomplete my original fix
for PR7463 actually was. We've been handling cv-qualifiers on rvalues
wrong for a very, very long time. Fixes PR7463.
llvm-svn: 108253
|
|
|
|
|
|
| |
suppressing copies of objects with trivial copy constructors.
llvm-svn: 107857
|
|
|
|
|
|
| |
breaking bootstrap on Linux.
llvm-svn: 107837
|
|
|
|
|
|
| |
newly-narrowed scope. No functionality change.
llvm-svn: 107828
|
|
|
|
|
|
|
|
| |
complex values either. Previously we did this properly for regular assignment,
but not for compound assignment.
- Also, tidy up assignment code a bit to look more like the scalar path.
llvm-svn: 107217
|
|
|
|
|
|
|
| |
types using property syntax to access setter/getters.
(also radar 7351147).
llvm-svn: 99307
|
|
|
|
|
|
| |
properties of complex type. Radar 7351147.
llvm-svn: 99299
|
|
|
|
|
|
| |
isInteger, we now have isFloatTy and isIntegerTy. Requested by Chris!
llvm-svn: 96224
|
|
|
|
|
|
| |
lvalue to poke, no functionality change.
llvm-svn: 93075
|
|
|
|
| |
llvm-svn: 92153
|
|
|
|
| |
llvm-svn: 90087
|
|
|
|
| |
llvm-svn: 90044
|
|
|
|
|
|
|
|
|
|
|
| |
Several of the existing methods were identical to their respective
specializations, and so have been removed entirely. Several more 'leaf'
optimizations were introduced.
The getAsFoo() methods which imposed extra conditions, like
getAsObjCInterfacePointerType(), have been left in place.
llvm-svn: 82501
|
|
|
|
| |
llvm-svn: 81337
|
|
|
|
|
|
|
|
| |
"ObjCImplctSetterGetterRefExpr".
A field rename and more comments.
llvm-svn: 79537
|
|
|
|
|
|
| |
- Several FIXMEs due to non-Twinification of IRBuilder.
llvm-svn: 79455
|
|
|
|
|
|
|
|
| |
Removed an unnecessary loop to get to setters incoming
argument. Added DoxyGen comments. Still more work
to do in this area (WIP).
llvm-svn: 79365
|
|
|
|
| |
llvm-svn: 77722
|
|
|
|
| |
llvm-svn: 77629
|
|
|
|
| |
llvm-svn: 77249
|
|
|
|
| |
llvm-svn: 77147
|
|
|
|
| |
llvm-svn: 77012
|
|
|
|
| |
llvm-svn: 75705
|
|
|
|
| |
llvm-svn: 75446
|
|
|
|
| |
llvm-svn: 73604
|
|
|
|
| |
llvm-svn: 73158
|
|
|
|
| |
llvm-svn: 72653
|
|
|
|
|
|
|
| |
any body can spot codegen bugs with volatile, or knows of any in the
bug database, let me know.
llvm-svn: 72572
|
|
|
|
| |
llvm-svn: 72457
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LHS type and the computation result type; this encodes information into
the AST which is otherwise non-obvious. Fix Sema to always come up with the
right answer for both of these types. Fix IRGen and the analyzer to
account for these changes. This fixes PR2601. The approach is inspired
by PR2601 comment 2.
Note that this changes real *= complex in CodeGen from a silent
miscompilation to an explicit error.
I'm not really sure that the analyzer changes are correct, or how to
test them... someone more familiar with the analyzer should check those
changes.
llvm-svn: 67889
|
|
|
|
| |
llvm-svn: 67501
|
|
|
|
|
|
| |
chosen sub-expression, rather than just evaluating the condition.
llvm-svn: 66018
|
|
|
|
| |
llvm-svn: 64961
|
|
|
|
|
|
| |
case on x86_64.
llvm-svn: 64333
|