maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGenCXX/address-of-fntemplate.cpp

28 lines
503 B
C++
Raw Normal View History

Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'. - This is designed to make it obvious that %clang_cc1 is a "test variable" which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it can be useful to redefine what gets run as 'clang -cc1' (for example, to set a default target). llvm-svn: 91446
2009-12-16 04:14:24 +08:00
// RUN: %clang_cc1 %s -emit-llvm -o - | FileCheck %s
Don't add implicit casts of explicit address-taking of overloaded functions. Taking the address of an overloaded function with an explicit address-of operator wrapped the operator in an implicit cast that added yet another pointer level, leaving us with a corrupted AST, which crashed CodeGen in the test case I've added. Fix this by making FixOverloadedFunctionReference return whether there was an address-of operator and not adding the implicit cast in that case. llvm-svn: 84362
2009-10-18 04:50:27 +08:00
template <typename T> void f(T) {}
Change FixOverloadedFunctionReference to return a (possibly new) expression. Substitute TemplateIdRefExprs with DeclRefExprs. Doug, plz review :) llvm-svn: 84763
2009-10-22 01:16:23 +08:00
template <typename T> void f() { }
Don't add implicit casts of explicit address-taking of overloaded functions. Taking the address of an overloaded function with an explicit address-of operator wrapped the operator in an implicit cast that added yet another pointer level, leaving us with a corrupted AST, which crashed CodeGen in the test case I've added. Fix this by making FixOverloadedFunctionReference return whether there was an address-of operator and not adding the implicit cast in that case. llvm-svn: 84362
2009-10-18 04:50:27 +08:00
void test() {
// CHECK: @_Z1fIiEvT_
void (*p)(int) = &f;
Change FixOverloadedFunctionReference to return a (possibly new) expression. Substitute TemplateIdRefExprs with DeclRefExprs. Doug, plz review :) llvm-svn: 84763
2009-10-22 01:16:23 +08:00
// CHECK: @_Z1fIiEvv
void (*p2)() = f<int>;
Don't add implicit casts of explicit address-taking of overloaded functions. Taking the address of an overloaded function with an explicit address-of operator wrapped the operator in an implicit cast that added yet another pointer level, leaving us with a corrupted AST, which crashed CodeGen in the test case I've added. Fix this by making FixOverloadedFunctionReference return whether there was an address-of operator and not adding the implicit cast in that case. llvm-svn: 84362
2009-10-18 04:50:27 +08:00
}
When resolving the address of an overloaded function or function template, mark the result as referenced. The most important effect of this is that function templates only referenced by address expressions now get instantiated. This, in turn, means that Hello World compiles with the Apache stdcxx library even when using endl. llvm-svn: 84363
2009-10-18 05:12:09 +08:00
// CHECK: define linkonce_odr void @_Z1fIiEvT_
Change FixOverloadedFunctionReference to return a (possibly new) expression. Substitute TemplateIdRefExprs with DeclRefExprs. Doug, plz review :) llvm-svn: 84763
2009-10-22 01:16:23 +08:00
// CHECK: define linkonce_odr void @_Z1fIiEvv
When determining a standard conversion sequence involves resolving the address of an overloaded function (or function template), perform that resolution prior to determining the implicit conversion sequence. This resolution is not part of the implicit conversion sequence itself. Previously, we would always consider this resolution to be a function pointer decay, which was a lie: there might be an explicit & in the expression, in which case decay should not occur. This caused the CodeGen assertion in PR6973 (where we created a pointer to a pointer to a function when we should have had a pointer to a function), but it's likely that there are corner cases of overload resolution where this would have failed. Cleaned up the code involved in determining the type that will produced afer resolving the overloaded function reference, and added an assertion to make sure the result is correct. Fixes PR6973. llvm-svn: 102650
2010-04-30 02:24:40 +08:00
namespace PR6973 {
template<typename T>
struct X {
void f(const T&);
};
template<typename T>
int g();
void h(X<int (*)()> xf) {
xf.f(&g<int>);
}
}