summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGenCXX/template-instantiation.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Revert "[CodeGenCXX] Treat 'this' as noalias in constructors"Sean Fertile2018-10-151-1/+1
| | | | | | | This reverts commit https://reviews.llvm.org/rL344150 which causes MachineOutliner related failures on the ppc64le multistage buildbot. llvm-svn: 344526
* [CodeGenCXX] Treat 'this' as noalias in constructorsAnton Bikineev2018-10-101-1/+1
| | | | | | | | | This is currently a clang extension and a resolution of the defect report in the C++ Standard. Differential Revision: https://reviews.llvm.org/D46441 llvm-svn: 344150
* [Test] Make Lit tests C++11 compatible - IR orderingCharles Li2017-03-011-19/+20
| | | | | | Differential Revision: https://reviews.llvm.org/D30430 llvm-svn: 296549
* Make '-disable-llvm-optzns' an alias for '-disable-llvm-passes'.Chandler Carruth2016-12-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Much to my surprise, '-disable-llvm-optzns' which I thought was the magical flag I wanted to get at the raw LLVM IR coming out of Clang deosn't do that. It still runs some passes over the IR. I don't want that, I really want the *raw* IR coming out of Clang and I strongly suspect everyone else using it is in the same camp. There is actually a flag that does what I want that I didn't know about called '-disable-llvm-passes'. I suspect many others don't know about it either. It both does what I want and is much simpler. This removes the confusing version and makes that spelling of the flag an alias for '-disable-llvm-passes'. I've also moved everything in Clang to use the 'passes' spelling as it seems both more accurate (*all* LLVM passes are disabled, not just optimizations) and much easier to remember and spell correctly. This is part of simplifying how Clang drives LLVM to make it cleaner to wire up to the new pass manager. Differential Revision: https://reviews.llvm.org/D28047 llvm-svn: 290392
* Assume loads fix #2Piotr Padlewski2015-08-271-2/+1
| | | | | | | | | | | | | There was linker problem, and it turns out that it is not always safe to refer to vtable. If the vtable is used, then we can refer to it without any problem, but because we don't know when it will be used or not, we can only check if vtable is external or it is safe to to emit it speculativly (when class it doesn't have any inline virtual functions). It should be fixed in the future. http://reviews.llvm.org/D12385 llvm-svn: 246214
* Generating assumption loads of vptr after ctor call (fixed)Piotr Padlewski2015-08-271-1/+2
| | | | | | | | | | | | | | | Generating call assume(icmp %vtable, %global_vtable) after constructor call for devirtualization purposes. For more info go to: http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html Edit: Fixed version because of PR24479. http://reviews.llvm.org/D11859 llvm-svn: 246213
* Revert "Generating assumption loads of vptr after ctor call (fixed)"Piotr Padlewski2015-08-211-2/+1
| | | | | | | | Reverting because of 245721 This reverts commit 552658e2b60543c928030b09cc9b5dfcb40c3f28. llvm-svn: 245727
* Generating assumption loads of vptr after ctor call (fixed)Piotr Padlewski2015-08-211-1/+2
| | | | | | | | | | | | | | | Generating call assume(icmp %vtable, %global_vtable) after constructor call for devirtualization purposes. For more info go to: http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html Edit: Fixed version because of PR24479. http://reviews.llvm.org/D11859 llvm-svn: 245721
* Revert "Generating assumption loads of vptr after ctor call (fixed)"Justin Bogner2015-08-181-2/+1
| | | | | | | | | | | Bootstrap bots were failing: http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_build/6382/ http://bb.pgr.jp/builders/clang-3stage-i686-linux/builds/2969 This reverts r245264. llvm-svn: 245267
* Generating assumption loads of vptr after ctor call (fixed)Piotr Padlewski2015-08-181-1/+2
| | | | | | | | | | | | | | | Generating call assume(icmp %vtable, %global_vtable) after constructor call for devirtualization purposes. For more info go to: http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html Edit: Fixed version because of PR24479. http://reviews.llvm.org/D11859 llvm-svn: 245264
* Revert r245257 "Generating assumption loads of vptr after ctor call"Hans Wennborg2015-08-181-2/+1
| | | | | | It caused PR24479 llvm-svn: 245260
* Generating assumption loads of vptr after ctor callPiotr Padlewski2015-08-171-1/+2
| | | | | | | | | | | | Generating call assume(icmp %vtable, %global_vtable) after constructor call for devirtualization purposes. For more info go to: http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html http://reviews.llvm.org/D11859 llvm-svn: 245257
* CodeGen: Fix linkage of reference temporariesDavid Majnemer2014-04-281-2/+2
| | | | | | | | | | | | | | | Summary: A reference temporary should inherit the linkage of the variable it initializes. Otherwise, we may hit cases where a reference temporary wouldn't have the same value in all translation units. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D3515 llvm-svn: 207451
* Fix a bug where an explicit instantiation declaration of a class templateRichard Smith2014-03-241-5/+19
| | | | | | specialization would make us think it might have a key function. llvm-svn: 204686
* CHECK-LABEL-ify some code gen tests to improve diagnostic experience when ↵Stephen Lin2013-08-151-10/+10
| | | | | | tests fail. llvm-svn: 188447
* Disable llvm optimizations in a clang test.Rafael Espindola2012-06-221-2/+2
| | | | llvm-svn: 159012
* Always mark friend function declarations in class templates asChandler Carruth2011-08-181-0/+36
| | | | | | | | | | | implicitly instantiable, even if we don't see a body on the friend function declaration. The body may simply have not yet been attached. This fixes PR10666. There may be an alternate, preferred implementation strategy, see my FIXME. Review would definitely be appreciated Doug. =D llvm-svn: 137934
* Enhance Clang to start instantiating static data member definitionsChandler Carruth2011-05-271-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | within class templates when they are necessary to complete the type of the member. The canonical example is code like: template <typename T> struct S { static const int arr[]; static const int x; static int f(); }; template <typename T> const int S<T>::arr[] = { 1, 2, 3 }; template <typename T> const int S<T>::x = sizeof(arr) / sizeof(arr[0]); template <typename T> int S<T>::f() { return x; } int x = S<int>::f(); We need to instantiate S<T>::arr's definition to pick up its initializer and complete the array type. This involves new code to specially handle completing the type of an expression where the type alone is insufficient. It also requires *updating* the expression with the newly completed type. Fortunately, all the other infrastructure is already in Clang to do the instantiation, do the completion, and prune out the unused bits of code that result from this instantiation. This addresses the initial bug in PR10001, and will be a step to fleshing out other cases where we need to work harder to complete an expression's type. Who knew we still had missing C++03 "features"? llvm-svn: 132172
* Move unnamed_addr after the function arguments on Sabre's request.Rafael Espindola2011-01-251-1/+1
| | | | llvm-svn: 124210
* Add unnamed_addr to vtables.Rafael Espindola2011-01-111-1/+1
| | | | llvm-svn: 123272
* Add unnamed_addr to constructors and destructors.Rafael Espindola2011-01-111-1/+1
| | | | llvm-svn: 123197
* Don't instantiate members not belonging in the semantic context of the template.Argyrios Kyrtzidis2010-11-041-0/+13
| | | | | | | | | | | | | | | e.g. for: template <int i> class A { class B *g; }; 'class B' has the template as lexical context but semantically it is introduced in namespace scope. Fixes rdar://8611125 & http://llvm.org/PR8505 llvm-svn: 118235
* White-listing templated-scope friend decls is a good idea, but doing itJohn McCall2010-10-161-0/+17
| | | | | | | | by marking the decl invalid isn't. Make some steps towards supporting these and then hastily shut them down at the last second by marking them as unsupported. llvm-svn: 116661
* Embrace C++ ABI 5.2.6 and consider that template instantiations don't have ↵Argyrios Kyrtzidis2010-10-131-0/+17
| | | | | | key functions (same as GCC). llvm-svn: 116391
* Reinstate the optimization suppressing available_externally functionsDouglas Gregor2010-07-131-1/+1
| | | | | | | | at -O0. The only change from the previous patch is that we don't try to generate virtual method thunks for an available_externally function. llvm-svn: 108230
* Speculatively revert r108156; it appears to be breaking self-host.Douglas Gregor2010-07-121-1/+1
| | | | llvm-svn: 108194
* Do not generate LLVM IR for available_externally function bodies atDouglas Gregor2010-07-121-1/+1
| | | | | | | | | | -O0, since we won't be using the definitions for anything anyway. For lib/System/Path.o when built in Debug+Asserts mode, this leads to a 4% improvement in compile time (and suppresses 440 function bodies). <rdar://problem/7987644> llvm-svn: 108156
* Turn access control on by default in -cc1.John McCall2010-04-091-0/+1
| | | | | | | | Remove -faccess-control from -cc1; add -fno-access-control. Make the driver pass -fno-access-control by default. Update a bunch of tests to be correct under access control. llvm-svn: 100880
* Don't produce a vtable if we are just instantiating a method and theRafael Espindola2010-03-301-0/+14
| | | | | | | | class has no key function. Fix PR6738. llvm-svn: 99900
* Discussing with dgregor we decided that we should not force the emission ofRafael Espindola2010-03-241-0/+62
implicit methods on explicit template instantiation definitions. As a consequence, we should emit them at every use, even if we see a explicit template instantiation declaration. This is already the current behaviour, but it is good to test for that :-) llvm-svn: 99443
OpenPOWER on IntegriCloud