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/dso-local-executable.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

81 lines
2.9 KiB
C++
Raw Normal View History

[Clang] Disable new PM for tests that use optimization level -O1, -O2 and -O3 Tests that use -O1, -O2 and -O3 would often produce different results with the new pass manager which makes these tests fail. Disable new PM explicitly for these tests. Differential Revision: https://reviews.llvm.org/D58375 llvm-svn: 362580
2019-06-05 11:17:11 +08:00
// RUN: %clang_cc1 -triple x86_64-pc-linux -mrelocation-model static -O1 -fno-experimental-new-pass-manager -emit-llvm %s -o - | FileCheck --check-prefix=STATIC %s
// RUN: %clang_cc1 -triple x86_64-pc-linux -mrelocation-model static -fno-plt -O1 -fno-experimental-new-pass-manager -emit-llvm %s -o - | FileCheck --check-prefix=NOPLT %s
// RUN: %clang_cc1 -triple x86_64-w64-mingw32 -O1 -fno-experimental-new-pass-manager -emit-llvm %s -o - | FileCheck --check-prefix=MINGW %s
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
// STATIC-DAG: @_ZTV1C = linkonce_odr dso_local unnamed_addr constant
// STATIC-DAG: @_ZTS1C = linkonce_odr dso_local constant
// STATIC-DAG: @_ZTI1C = linkonce_odr dso_local constant
// STATIC-DAG: @_ZZ14useStaticLocalvE3obj = linkonce_odr dso_local global
// STATIC-DAG: @_ZGVZN5guard1gEvE1a = linkonce_odr dso_local global
// STATIC-DAG: define dso_local void @_ZN1CC2Ev(
// STATIC-DAG: define dso_local void @_ZN1CC1Ev(
// STATIC-DAG: define linkonce_odr dso_local void @_ZN1C3fooEv(
// NOPLT-DAG: @_ZTV1C = linkonce_odr dso_local unnamed_addr constant
// NOPLT-DAG: @_ZTS1C = linkonce_odr dso_local constant
// NOPLT-DAG: @_ZTI1C = linkonce_odr dso_local constant
// NOPLT-DAG: @_ZZ14useStaticLocalvE3obj = linkonce_odr dso_local global
// NOPLT-DAG: @_ZGVZN5guard1gEvE1a = linkonce_odr dso_local global
// NOPLT-DAG: define dso_local void @_ZN1CC2Ev(
// NOPLT-DAG: define dso_local void @_ZN1CC1Ev(
// NOPLT-DAG: define linkonce_odr dso_local void @_ZN1C3fooEv(
[MinGW] Don't mark external variables as DSO local Since MinGW supports automatically importing external variables from DLLs even without the DLLImport attribute, we shouldn't mark them as DSO local unless we actually know them to be local for sure. Keep marking thread local variables as DSO local. Differential Revision: https://reviews.llvm.org/D51382 llvm-svn: 340941
2018-08-30 01:26:58 +08:00
// MINGW-DAG: @_ZTV1C = linkonce_odr dso_local unnamed_addr constant
// MINGW-DAG: @_ZTS1C = linkonce_odr dso_local constant
// MINGW-DAG: @_ZTI1C = linkonce_odr dso_local constant
// MINGW-DAG: @_ZZ14useStaticLocalvE3obj = linkonce_odr dso_local global
// MINGW-DAG: @_ZGVZN5guard1gEvE1a = linkonce_odr dso_local global
// MINGW-DAG: define dso_local void @_ZN1CC2Ev(
// MINGW-DAG: define dso_local void @_ZN1CC1Ev(
// MINGW-DAG: define linkonce_odr dso_local void @_ZN1C3fooEv(
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
struct C {
C();
virtual void foo() {}
};
C::C() {}
struct HasVTable {
virtual void f();
};
inline HasVTable &useStaticLocal() {
static HasVTable obj;
return obj;
}
void useit() {
useStaticLocal();
}
namespace guard {
int f();
inline int g() {
static int a = f();
return a;
}
int h() {
return g();
}
} // namespace guard
[MinGW] Don't mark external variables as DSO local Since MinGW supports automatically importing external variables from DLLs even without the DLLImport attribute, we shouldn't mark them as DSO local unless we actually know them to be local for sure. Keep marking thread local variables as DSO local. Differential Revision: https://reviews.llvm.org/D51382 llvm-svn: 340941
2018-08-30 01:26:58 +08:00
// STATIC-DAG: @_ZN5test23barIiE1xE = available_externally dso_local constant i32
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
// STATIC-DAG: define available_externally dso_local void @_ZN5test23barIcEC1Ev(
[MinGW] Don't mark external variables as DSO local Since MinGW supports automatically importing external variables from DLLs even without the DLLImport attribute, we shouldn't mark them as DSO local unless we actually know them to be local for sure. Keep marking thread local variables as DSO local. Differential Revision: https://reviews.llvm.org/D51382 llvm-svn: 340941
2018-08-30 01:26:58 +08:00
// NOPLT-DAG: @_ZN5test23barIiE1xE = available_externally dso_local constant i32
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
// NOPLT-DAG: define available_externally void @_ZN5test23barIcEC1Ev(
[MinGW] Don't mark external variables as DSO local Since MinGW supports automatically importing external variables from DLLs even without the DLLImport attribute, we shouldn't mark them as DSO local unless we actually know them to be local for sure. Keep marking thread local variables as DSO local. Differential Revision: https://reviews.llvm.org/D51382 llvm-svn: 340941
2018-08-30 01:26:58 +08:00
// MINGW-DAG: @_ZN5test23barIiE1xE = available_externally constant i32
// MINGW-DAG: define available_externally dso_local void @_ZN5test23barIcEC1Ev(
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
namespace test2 {
void foo();
template <typename T>
struct bar {
virtual void zed();
[MinGW] Don't mark external variables as DSO local Since MinGW supports automatically importing external variables from DLLs even without the DLLImport attribute, we shouldn't mark them as DSO local unless we actually know them to be local for sure. Keep marking thread local variables as DSO local. Differential Revision: https://reviews.llvm.org/D51382 llvm-svn: 340941
2018-08-30 01:26:58 +08:00
static const int x = 42;
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
bar() { foo(); }
};
extern template class bar<char>;
bar<char> abc;
[MinGW] Don't mark external variables as DSO local Since MinGW supports automatically importing external variables from DLLs even without the DLLImport attribute, we shouldn't mark them as DSO local unless we actually know them to be local for sure. Keep marking thread local variables as DSO local. Differential Revision: https://reviews.llvm.org/D51382 llvm-svn: 340941
2018-08-30 01:26:58 +08:00
const int *getX() {
return &bar<int>::x;
}
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
} // namespace test2