- May 05, 2010
-
-
Douglas Gregor authored
destructors, place the __cxa_atexit call after the __cxa_guard_release call, mimicking GCC/LLVM-GCC behavior. Noticed while debugging something related. llvm-svn: 103088
-
Alexis Hunt authored
with no whitespace. This will allow statements to be referred to in attribute TableGen files. llvm-svn: 103087
-
Alexis Hunt authored
whitespace which makes this patch unreadable. Will recommit without the whitespace. llvm-svn: 103086
-
Douglas Gregor authored
implicitly-generated copy constructor. Previously, Sema would perform some checking and instantiation to determine which copy constructors, etc., would be called, then CodeGen would attempt to figure out which copy constructor to call... but would get it wrong, or poke at an uninstantiated default argument, or fail in other ways. The new scheme is similar to what we now do for the implicit copy-assignment operator, where Sema performs all of the semantic analysis and builds specific ASTs that look similar to the ASTs we'd get from explicitly writing the copy constructor, so that CodeGen need only do a direct translation. However, it's not quite that simple because one cannot explicit write elementwise copy-construction of an array. So, I've extended CXXBaseOrMemberInitializer to contain a list of indexing variables used to copy-construct the elements. For example, if we have: struct A { A(const A&); }; struct B { A array[2][3]; }; then we generate an implicit copy assignment operator for B that looks something like this: B::B(const B &other) : array[i0][i1](other.array[i0][i1]) { } CodeGen will loop over the invented variables i0 and i1 to visit all elements in the array, so that each element in the destination array will be copy-constructed from the corresponding element in the source array. Of course, if we're dealing with arrays of scalars or class types with trivial copy-assignment operators, we just generate a memcpy rather than a loop. Fixes PR6928, PR5989, and PR6887. Boost.Regex now compiles and passes all of its regression tests. Conspicuously missing from this patch is handling for the exceptional case, where we need to destruct those objects that we have constructed. I'll address that case separately. llvm-svn: 103079
-
Anders Carlsson authored
llvm-svn: 103078
-
Douglas Gregor authored
llvm-svn: 103077
-
Alexis Hunt authored
llvm-svn: 103072
-
- May 04, 2010
-
-
John McCall authored
they're unreachable. This matters because (if they're POD, or if this is C) the scope containing the variable might be reachable even if the variable isn't. Fixes PR7044. llvm-svn: 103052
-
Fariborz Jahanian authored
llvm-svn: 103028
-
Douglas Gregor authored
typedef int functype(int, int); functype func; also instantiate the synthesized function parameters for the resulting function declaration. With this change, Boost.Wave builds and passes all of its regression tests. llvm-svn: 103025
-
Fariborz Jahanian authored
(radar 7495203). llvm-svn: 103022
-
John McCall authored
not just the inner expression. This is important if the expression has any temporaries. Fixes PR 7028. Basically a symptom of really tragic method names. llvm-svn: 102998
-
Fariborz Jahanian authored
variabe. Blocks and their construction/destruction is wip though. llvm-svn: 102985
-
- May 03, 2010
-
-
John McCall authored
variable. Surprisingly, this does seem to be the right way to solve this. llvm-svn: 102961
-
Douglas Gregor authored
aggregate and the result of the aggregate is unused, bail out early. Fixes PR7027. llvm-svn: 102942
-
Anders Carlsson authored
When computing the address of a virtual member function pointer, use the pointer width instead of hardcoding for 64-bit. llvm-svn: 102921
-
Anders Carlsson authored
llvm-svn: 102912
-
Anders Carlsson authored
llvm-svn: 102891
-
Anders Carlsson authored
llvm-svn: 102890
-
Anders Carlsson authored
llvm-svn: 102889
-
Anders Carlsson authored
llvm-svn: 102888
-
Anders Carlsson authored
llvm-svn: 102887
-
Anders Carlsson authored
llvm-svn: 102886
-
Anders Carlsson authored
llvm-svn: 102885
-
Anders Carlsson authored
llvm-svn: 102883
-
Anders Carlsson authored
llvm-svn: 102882
-
Anders Carlsson authored
llvm-svn: 102881
-
Anders Carlsson authored
llvm-svn: 102880
-
- May 02, 2010
-
-
Anders Carlsson authored
llvm-svn: 102871
-
Anders Carlsson authored
llvm-svn: 102870
-
Benjamin Kramer authored
llvm-svn: 102863
-
David Chisnall authored
llvm-svn: 102862
-
- May 01, 2010
-
-
Douglas Gregor authored
assignment operators. Previously, Sema provided type-checking and template instantiation for copy assignment operators, then CodeGen would synthesize the actual body of the copy constructor. Unfortunately, the two were not in sync, and CodeGen might pick a copy-assignment operator that is different from what Sema chose, leading to strange failures, e.g., link-time failures when CodeGen called a copy-assignment operator that was not instantiation, run-time failures when copy-assignment operators were overloaded for const/non-const references and the wrong one was picked, and run-time failures when by-value copy-assignment operators did not have their arguments properly copy-initialized. This implementation synthesizes the implicitly-defined copy assignment operator bodies in Sema, so that the resulting ASTs encode exactly what CodeGen needs to do; there is no longer any special code in CodeGen to synthesize copy-assignment operators. The synthesis of the body is relatively simple, and we generate one of three different kinds of copy statements for each base or member: - For a class subobject, call the appropriate copy-assignment operator, after overload resolution has determined what that is. - For an array of scalar types or an array of class types that have trivial copy assignment operators, construct a call to __builtin_memcpy. - For an array of class types with non-trivial copy assignment operators, synthesize a (possibly nested!) for loop whose inner statement calls the copy constructor. - For a scalar type, use built-in assignment. This patch fixes at least a few tests cases in Boost.Spirit that were failing because CodeGen picked the wrong copy-assignment operator (leading to link-time failures), and I suspect a number of undiagnosed problems will also go away with this change. Some of the diagnostics we had previously have gotten worse with this change, since we're going through generic code for our type-checking. I will improve this in a subsequent patch. llvm-svn: 102853
-
Anders Carlsson authored
llvm-svn: 102849
-
Anders Carlsson authored
llvm-svn: 102848
-
Anders Carlsson authored
llvm-svn: 102846
-
Anders Carlsson authored
llvm-svn: 102845
-
Anders Carlsson authored
llvm-svn: 102842
-
David Chisnall authored
llvm-svn: 102839
-
David Chisnall authored
llvm-svn: 102837
-