summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGenCXX/implicit-copy-constructor.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Remove custom handling of array copies in lambda by-value array capture andRichard Smith2016-12-141-3/+5
| | | | | | | | | | | copy constructors of classes with array members, instead using ArrayInitLoopExpr to represent the initialization loop. This exposed a bug in the static analyzer where it was unable to differentiate between zero-initialized and unknown array values, which has also been fixed here. llvm-svn: 289618
* Mark C++ reference parameters as dereferenceableHal Finkel2014-07-181-1/+1
| | | | | | | | | | | | | | Because references must be initialized using some evaluated expression, they must point to something, and a callee can assume the reference parameter is dereferenceable. Taking advantage of a new attribute just added to LLVM, mark them as such. Because dereferenceability in addrspace(0) implies nonnull in the backend, we don't need both attributes. However, we need to know the size of the object to use the dereferenceable attribute, so for incomplete types we still emit only nonnull. llvm-svn: 213386
* Add 'nonnull' parameter or return attribute when producing an llvm pointer ↵Nick Lewycky2014-05-281-1/+1
| | | | | | type in a function type where the C++ type is a reference. Update the tests. llvm-svn: 209723
* CHECK-LABEL-ify some code gen tests to improve diagnostic experience when ↵Stephen Lin2013-08-151-1/+1
| | | | | | tests fail. llvm-svn: 188447
* Re-apply r174919 - smarter copy/move assignment/construction, with fixes forLang Hames2013-02-171-3/+2
| | | | | | | | | | | bitfield related issues. The original commit broke Takumi's builder. The bug was caused by bitfield sizes being determined by their underlying type, rather than the field info. A similar issue with bitfield alignments showed up on closer testing. Both have been fixed in this patch. llvm-svn: 175389
* Backing out r174919 while I investigate a self-host bug on Takumi's builder.Lang Hames2013-02-121-2/+3
| | | | llvm-svn: 174925
* When generating IR for default copy-constructors, copy-assignment operators,Lang Hames2013-02-111-3/+2
| | | | | | | | | | | | | | | | | | | | move-constructors and move-assignment operators, use memcpy to copy adjacent POD members. Previously, classes with one or more Non-POD members would fall back on element-wise copies for all members, including POD members. This often generated a lot of IR. Without padding metadata, it wasn't often possible for the LLVM optimizers to turn the element-wise copies into a memcpy. This code hasn't yet received any serious tuning. I didn't see any serious regressions on a self-hosted clang build, or any of the nightly tests, but I think it's important to get this out in the wild to get more testing. Insights, feedback and comments welcome. Many thanks to David Blaikie, Richard Smith, and especially John McCall for their help and feedback on this work. llvm-svn: 174919
* When deciding whether to convert an array construction loop into a memcpy, lookRichard Smith2012-11-071-1/+27
| | | | | | | | at whether the *selected* constructor would be trivial rather than considering whether the array's element type has *any* non-trivial constructors of the relevant kind. llvm-svn: 167562
* When synthesizing implicit copy/move constructors and copy/move assignmentJohn McCall2011-06-171-0/+10
| | | | | | | operators, don't make an initializer or sub-operation for zero-width bitfields. llvm-svn: 133221
* Move unnamed_addr after the function arguments on Sabre's request.Rafael Espindola2011-01-251-1/+1
| | | | llvm-svn: 124210
* Add unnamed_addr to constructors and destructors.Rafael Espindola2011-01-111-1/+1
| | | | llvm-svn: 123197
* Reimplement code generation for copying fields in theDouglas Gregor2010-05-051-0/+72
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
OpenPOWER on IntegriCloud