Douglas Gregor [Tue, 12 Jul 2011 06:55:29 +0000 (06:55 +0000)]
Fix the desugaring of dependent decltype and typeof(expr) nodes. The
isSugared() and desugar() routines previously provided were never
actually called, since the corresponding types
(DependentTypeOfExprType, DependentDecltypeType) don't have
corresponding type classes. Outside of the current (incomplete) patch
I'm working on, I haven't found a way to trigger this problem.
Chris Lattner [Tue, 12 Jul 2011 06:52:18 +0000 (06:52 +0000)]
Fix a problem Eli ran into where we now reject incomplete arrays of
uncompleted struct types. We now do what llvm-gcc does and compile
them into [i8 x 0]. If the type is later completed, we make sure that
it is appropriately cast.
We compile the terrible example to something like this now:
%struct.A = type { i32, i32, i32 }
@g = external global [0 x i8]
define void @_Z1fv() nounwind {
entry:
call void @_Z3fooP1A(%struct.A* bitcast ([0 x i8]* @g to %struct.A*))
ret void
}
declare void @_Z3fooP1A(%struct.A*)
define %struct.A* @_Z2f2v() nounwind {
entry:
ret %struct.A* getelementptr inbounds ([0 x %struct.A]* bitcast ([0 x i8]* @g to [0 x %struct.A]*), i32 0, i64 1)
}
[ARC] Complain about property without storage attribute when @synthesizing it, not at its declaration.
For this sample:
@interface Foo
@property id x;
@end
we get:
t.m:2:1: error: ARC forbids properties of Objective-C objects with unspecified storage attribute
@property id x;
^
1 error generated.
The error should be imposed on the implementor of the interface, not the user. If the user uses
a header of a non-ARC library whose source code he does not have, we are basically asking him to
go change the header of the library (bad in general), possible overriding how the property is
implemented if he gets confused and says "Oh I'll just add 'copy' then" (even worse).
Second issue is that we don't emit any error for 'readonly' properties, e.g:
@interface Foo
@property (readonly) id x; // no error here
@end
@implementation Foo
@synthesize x; // no error here too
@end
We should give an error when the implementor is @synthesizing a property which doesn't have
any storage specifier; this is when the explicit specifier is important, because we are
going to create an ivar and we want its ownership to be explicit.
Related improvements:
-OBJC_PR_unsafe_unretained turned out to not fit in ObjCPropertyDecl's bitfields, fix it.
-For properties of extension classes don't drop PropertyAttributesAsWritten values.
-Have PropertyAttributesAsWritten actually only reflect what the user wrote
Bill Wendling [Tue, 12 Jul 2011 01:16:47 +0000 (01:16 +0000)]
Revert r134888 (and related patches in other trees). It was causing
an assert on Darwin llvm-gcc builds.
Assertion failed: (castIsValid(op, S, Ty) && "Invalid cast!"), function Create, file /Users/buildslave/zorg/buildbot/smooshlab/slave-0.8/build.llvm-gcc-i386-darwin9-RA/llvm.src/lib/VMCore/Instructions.cpp, line 2067.
etc.
Fix one x86_64 abi issue and the test to actually look for the right thing,
which is: { <4 x float>, <4 x float> } should continue to go through memory.
Disable avx feature from corei7-avx, and use -mavx for now. Right now, if -mavx is
specified, 128 avx code is used and we're not sure yet if this the behavior
we want (and if it does, some improvements are needed before relying on it).
objc-arc: Diagnose when captured variable in block literals
require destruction and there is possibility of that without
construction. Thanks Johnm for review and suggestions offline.
// rdar://9535237.
When two different types has the same text representation in the same
diagnostic message, print an a.k.a. after the type if the a.k.a. gives extra
information about the type.
class versa_string;
typedef versa_string string;
namespace std {template <typename T> class vector;}
Old message:
----------------
test.cc:15:3: error: no matching function for call to 'f'
f(&v);
^
test.cc:7:6: note: candidate function not viable: no known conversion from
'vector<string>' to 'vector<string>' for 1st argument
void f(vector<string> v);
^
1 error generated.
New message:
---------------
test.cc:15:3: error: no matching function for call to 'f'
f(v);
^
test.cc:7:6: note: candidate function not viable: no known conversion from
'vector<string>' (aka 'std::vector<std::basic_string>') to
'vector<string>' (aka 'std::vector<versa_string>') for 1st argument
void f(vector<string> v);
^
1 error generated.
John McCall [Mon, 11 Jul 2011 08:38:19 +0000 (08:38 +0000)]
Fix a lot of problems with the partial destruction of arrays:
- an off-by-one error in emission of irregular array limits for
InitListExprs
- use an EH partial-destruction cleanup within the normal
array-destruction cleanup
- get the branch destinations right for the empty check
Also some refactoring which unfortunately obscures these changes.
Chris Lattner [Sun, 10 Jul 2011 06:03:22 +0000 (06:03 +0000)]
implement a nice new optimization: CodeGenTypes::UpdateCompletedType
is called whenever a tag type is completed. We previously used that
as the sign to layout the codegen representation for the tag type,
which worked but meant that we laid out *every* completed type, whether
it was used or not.
Now we just lay out the type if we've already seen it somehow else.
This means that we lay out types we've used but haven't seen a body
for, but we don't lay out tons of stuff that noone cares about.
Chris Lattner [Sun, 10 Jul 2011 05:53:24 +0000 (05:53 +0000)]
enhance EmitLValueForFieldInitialization to do the proper pointer adjustment, allowing
us to revert the other half of r134860. Now things are back to a relatively tidy state.
Chris Lattner [Sun, 10 Jul 2011 05:39:13 +0000 (05:39 +0000)]
keep track of whether being in a RS_StructPointer state
caused us to skip layout out a function accurately. If
so, flush the type cache for both the function and struct
case to ensure that any pointers to the functions get
recomputed. This is overconservative, but with this patch
clang can build itself again.
Chris Lattner [Sun, 10 Jul 2011 05:34:54 +0000 (05:34 +0000)]
change EmitLValueForField to cast the returned lvalue to the right
type, even when in the struct case. This was one root issue that was
causing type mismatches throughout the compiler.
Chris Lattner [Sun, 10 Jul 2011 03:47:27 +0000 (03:47 +0000)]
Fix the clang bootstrap and Jay's testcase from llvm-dev by being completely
conservative when converting a functiontype to IR when in a "pointer within
a struct" context. This has the unfortunate sideeffect of compiling all
function pointers inside of structs into "{}*" which, though correct, is
ugly. This has the positive side effect of being correct, and it is pretty
straight-forward to improve on this.
Chris Lattner [Sun, 10 Jul 2011 03:38:35 +0000 (03:38 +0000)]
when emitting pointer load from an lvalue or storing to an lvalue,
do an explicit bitcast to whatever ConvertType produces. This will
go with the next patch.
Chris Lattner [Sun, 10 Jul 2011 00:18:59 +0000 (00:18 +0000)]
Rename CGT::VerifyFuncTypeComplete to isFuncTypeConvertible since
it is a predicate, not an action. Change the return type to be a bool,
not the incomplete member. Enhace it to detect the recursive compilation
case, allowing us to compile Eli's testcase on llvmdev:
struct T {
struct T (*p)(void);
} t;
into:
%struct.T = type { {}* }
@t = common global %struct.T zeroinitializer, align 8
[arcmt] Introduce new '-ccc-arcmt-migrate <path>' ARC migration driver option.
This is a new mode of migration, where we avoid modifying the original files but
we emit temporary files instead.
<path> will be used to keep migration process metadata. Currently the temporary files
that are produced are put in the system's temp directory but we can put them
in the <path> if is necessary.
Also introduce new ARC migration functions in libclang whose only purpose,
currently, is to accept <path> and provide pairs of original file/transformed file
to map from the originals to the files after transformations are applied.
Finally introduce the c-arcmt-test utility that exercises the new libclang functions,
update arcmt-test, and add tests for the whole process.
Chris Lattner [Sat, 9 Jul 2011 18:53:56 +0000 (18:53 +0000)]
when an enum type is completed, only flush the type cache when
the enum has already been converted. If not, there cannot be any types
built on top of it, so there is no need to flush the cache.
John McCall [Sat, 9 Jul 2011 09:09:00 +0000 (09:09 +0000)]
More compiler workarounds. I have to admit that I was not
expecting so much concentrated oddity on what seemed like a
trivial feature. Thanks to François Pichet for doing the
MSVC legwork here.
John McCall [Sat, 9 Jul 2011 01:37:26 +0000 (01:37 +0000)]
A number of array-related IR-gen cleanups.
- Emit default-initialization of arrays that were partially initialized
with initializer lists with a loop, rather than emitting the default
initializer N times;
- support destroying VLAs of non-trivial type, although this is not
yet exposed to users; and
- support the partial destruction of arrays initialized with
initializer lists when an initializer throws an exception.
Eli Friedman [Fri, 8 Jul 2011 23:31:17 +0000 (23:31 +0000)]
Change -mno-mmx to be more compatible with gcc. Specifically, -mno-mmx should not imply -mno-sse.
Note that because we don't usually touch the MMX registers anyway, all -mno-mmx needs to do is tweak the x86-32 calling convention a little for vectors that look like MMX vectors, and prevent the definition of __MMX__.
clang doesn't actually stop the user from using MMX inline asm operands or MMX builtins in -mno-mmx mode; as a QOI issue, it would be nice to diagnose, but I doubt it really matters much.
Eli Friedman [Fri, 8 Jul 2011 20:17:28 +0000 (20:17 +0000)]
Fix up dependency file name printing to more closely match that of gcc, including fixing a nasty recent regression that could make us print "/foo.h" with a command-line including "-I ./".
Douglas Gregor [Fri, 8 Jul 2011 15:50:43 +0000 (15:50 +0000)]
Teach CXXUnresolvedConstructExpr when it should be an
lvalue/xvalue/rvalue, rather than just (incorrectly) assuming it's an
lvalue. Fixes PR10285 / <rdar://problem/9743926>.
Add several CFG-stress-testing input source files. These use the
preprocessor to build up very large CFGs in various shapes that can
produce different algorithmic behavior in CFG-walking code.
Make the worklist in the uninitialized values checker actually a queue.
Previously, despite the names 'enqueue' and 'dequeue', it behaved as
a stack and visited blocks in a LIFO fashion. This interacts badly with
extremely broad CFGs *inside* of a loop (such as a large switch inside
a state machine) where every block updates a different variable.
When encountering such a CFG, the checker visited blocks in essentially
a "depth first" order due to the stack-like behavior of the work list.
Combined with each block updating a different variable, the saturation
logic of the checker caused it to re-traverse blocks [1,N-1] of the
broad CFG inside the loop after traversing block N. These re-traversals
were to propagate the variable values derived from block N. Assuming
approximately the same number of variables as inner blocks exist, the
end result is O(N^2) updates. By making this a queue, we also make the
traversal essentially "breadth-first" across each of the N inner blocks
of the loop. Then all of this state is propagated around to all N inner
blocks of the loop. The result is O(N) updates.
The truth is in the numbers:
Before, gcc.c: 96409 block visits (max: 61546, avg: 591)
After, gcc.c: 69958 block visits (max: 33090, avg: 429)
Before, PR10183: 2540494 block vists (max: 2536495, avg: 37360)
After, PR10183: 137803 block visits (max: 134406, avg: 2026)
The nearly 20x reduction in work for PR10183 corresponds to a roughly
100x speedup in compile time.
I've tested it on all the code I can get my hands on, and I've seen no
slowdowns due to this change. Where I've collected stats, the ammount of
work done is on average less. I'll also commit shortly some synthetic
test cases useful in analyzing the performance of CFG-based warnings.
Submitting this based on Doug's feedback that post-commit review should
be good. Ted, please review! Hopefully this helps compile times until
then.
Fix a FIXME in clang ARM driver that was exposed as a bug with ARM backend
change.
Previously clang was passing the following feature strings to the ARM backend
when CPU is cortex-a8: +neon,-vfp2,-vfp3
This used to work because -vfp2,-vfp3 had no effect after +neon. Now that the
features are controlled by individual bits (with implied hierarchy), the net
effect is all three features will be turned off.
Remove a no-op break after a return, and correct one of the most
confusing indentations I've seen recently... Just noticed these while
making a change elsewhere.
Switch the token-paste source locations inside of function style macro
argument expansion to use the macro argument source locations as well.
Add a few tests to exercise this. There is still a bit more work needed
here though.
projects / clang / log