replica
/
hanchenye-llvm-project
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
hanchenye-llvm-project/clang/test/Driver/rtti-options.cpp

49 lines
3.3 KiB
C++
Raw Normal View History

Add some more PS4 driver settings related to rtti and exceptions. Summary: The PS4 defaults to -fno-rtti, and has to have rtti enabled when enabling exceptions. This commit makes clang add the -fno-rtti by default on the PS4, unless -frtti was passed in. It also diagnoses misuses for the PS4: - Exceptions need rtti. Warn and enable rtti if no rtti flag was passed, error if -fno-rtti was passed. I also added a more general warning for when -fno-rtti is the default (currently it's only on the PS4) and the vptr sanitizer is on. Fixed a few tests, due to different flag order when passing cc1 arguments. Reviewers: chandlerc Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D7250 llvm-svn: 227518
2015-01-30 07:56:43 +08:00
// Check that we emit warnings/errors for different combinations of
Do not enable RTTI with -fexceptions, for PS4 NFC for targets other than PS4. This patch is a change in behavior for PS4, in that PS4 will no longer enable RTTI when -fexceptions is specified (RTTI and Exceptions are disabled by default on PS4). RTTI will remain disabled except for types being thrown or caught. Also, '-fexceptions -fno-rtti' (previously prohibited on PS4) is now accepted, as it is for other targets. This patch removes some PS4 specific code, making the code cleaner. Also, in the test file rtti-options.cpp, PS4 tests where the behavior is the same as the generic x86_64-linux are removed, making the test cleaner. Differential Revision: https://reviews.llvm.org/D46982 llvm-svn: 332784
2018-05-19 07:32:01 +08:00
// exceptions, rtti, and vptr sanitizer flags for generic (unknown) x86 linux,
// and for PS4 when its behaviour differs from the generic x86-linux.
Add some more PS4 driver settings related to rtti and exceptions. Summary: The PS4 defaults to -fno-rtti, and has to have rtti enabled when enabling exceptions. This commit makes clang add the -fno-rtti by default on the PS4, unless -frtti was passed in. It also diagnoses misuses for the PS4: - Exceptions need rtti. Warn and enable rtti if no rtti flag was passed, error if -fno-rtti was passed. I also added a more general warning for when -fno-rtti is the default (currently it's only on the PS4) and the vptr sanitizer is on. Fixed a few tests, due to different flag order when passing cc1 arguments. Reviewers: chandlerc Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D7250 llvm-svn: 227518
2015-01-30 07:56:43 +08:00
// No warnings/errors should be emitted for unknown, except if combining
// the vptr sanitizer with -fno-rtti
Only add -fno-rtti if KernelOrKext or in C++ mode. llvm-svn: 232869
2015-03-21 07:51:15 +08:00
// Special cases: -fcxx-exceptions in C code should warn about unused arguments
// We should also not have any rtti-related arguments
Fixed some rtti-options tests. Certain tests in rtti-options.cpp are not really testing anything because they are testing for the absence of -frtti option to the cc1 process. Since the cc1 process does not take -frtti option, these tests are passing tautologically. The RTTI mode is enabled by default in cc1, and -fno-rtti disables it. Therefore the correct way to check for enabling of RTTI is to check for the absence of -fno-rtti to cc1, and the correct way to check for disabling of RTTI is to check for the presence of -fno-rtti to cc1. This patch fixes those tests. Differential Revision: https://reviews.llvm.org/D46836 llvm-svn: 332384
2018-05-16 02:28:42 +08:00
// RUN: %clang -x c -### -target x86_64-unknown-unknown -c -fcxx-exceptions %s 2>&1 | FileCheck -check-prefix=CHECK-UNUSED -check-prefix=CHECK-RTTI %s
Don't claim exception related arguments when looking at RTTIMode Summary: We were claiming the -f*exceptions arguments when looking for the RTTIMode. This makes us not warn about unused arguments if compiling a C file with -fcxx-exceptions. This patch fixes it by not claiming the exception-related arguments at that point. Reviewers: rsmith, samsonov Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D8507 llvm-svn: 232860
2015-03-21 07:33:23 +08:00
Only add -fno-rtti if KernelOrKext or in C++ mode. llvm-svn: 232869
2015-03-21 07:51:15 +08:00
// Make sure we keep the last -frtti/-fno-rtti argument
Improve our handling of rtti/sanitize=vptr/sanitize=undefined This patch removes the huge blob of code that is dealing with rtti/exceptions/sanitizers and replaces it with: A ToolChain function which, for a given set of Args, figures out if rtti should be: - enabled - disabled implicitly - disabled explicitly A change in the way SanitizerArgs figures out what sanitizers to enable (or if it should error out, or warn); And a check for exceptions/rtti interaction inside addExceptionArgs. The RTTIMode algorithm is: - If -mkernel, -fapple-kext, or -fno-rtti are passed, rtti was disabled explicitly; - If -frtti was passed or we're not targetting the PS4, rtti is enabled; - If -fexceptions or -fcxx-exceptions was passed and we're targetting the PS4, rtti was enabled implicitly; - If we're targetting the PS4, rtti is disabled implicitly; - Otherwise, rtti is enabled; Since the only flag needed to pass to -cc1 is -fno-rtti if we want to disable it, there's no problem in saying rtti is enabled if we're compiling C code, so we don't look at the input file type. addExceptionArgs now looks at the RTTIMode and warns that rtti is being enabled implicitly if targetting the PS4 and exceptions are on. It also errors out if, targetting the PS4, -fno-rtti was passed, and exceptions were turned on. SanitizerArgs now errors out if rtti was disabled explicitly and the vptr sanitizer was enabled implicitly, but just turns off vptr if rtti is disabled but -fsanitize=undefined was passed. Also fixed tests, removed duplicate name from addExceptionArgs comment, and added one or two surrounding lines when running clang-format. This changes test/Driver/fsanitize.c to make it not expect a warning when passed -fsanitize=undefined -fno-rtti, but expect vptr to not be on. Removed all users and definition of SanitizerArgs::sanitizesVptr(). Reviewers: samsonov Subscribers: llvm-commits, samsonov, rsmith Differential Revision: http://reviews.llvm.org/D7525 llvm-svn: 229801
2015-02-19 09:04:49 +08:00
// RUN: %clang -### -c -fno-rtti -frtti %s 2>&1 | FileCheck -check-prefix=CHECK-RTTI %s
// RUN: %clang -### -c -frtti -fno-rtti %s 2>&1 | FileCheck -check-prefix=CHECK-NO-RTTI %s
Add some more PS4 driver settings related to rtti and exceptions. Summary: The PS4 defaults to -fno-rtti, and has to have rtti enabled when enabling exceptions. This commit makes clang add the -fno-rtti by default on the PS4, unless -frtti was passed in. It also diagnoses misuses for the PS4: - Exceptions need rtti. Warn and enable rtti if no rtti flag was passed, error if -fno-rtti was passed. I also added a more general warning for when -fno-rtti is the default (currently it's only on the PS4) and the vptr sanitizer is on. Fixed a few tests, due to different flag order when passing cc1 arguments. Reviewers: chandlerc Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D7250 llvm-svn: 227518
2015-01-30 07:56:43 +08:00
// -fsanitize=vptr
Improve our handling of rtti/sanitize=vptr/sanitize=undefined This patch removes the huge blob of code that is dealing with rtti/exceptions/sanitizers and replaces it with: A ToolChain function which, for a given set of Args, figures out if rtti should be: - enabled - disabled implicitly - disabled explicitly A change in the way SanitizerArgs figures out what sanitizers to enable (or if it should error out, or warn); And a check for exceptions/rtti interaction inside addExceptionArgs. The RTTIMode algorithm is: - If -mkernel, -fapple-kext, or -fno-rtti are passed, rtti was disabled explicitly; - If -frtti was passed or we're not targetting the PS4, rtti is enabled; - If -fexceptions or -fcxx-exceptions was passed and we're targetting the PS4, rtti was enabled implicitly; - If we're targetting the PS4, rtti is disabled implicitly; - Otherwise, rtti is enabled; Since the only flag needed to pass to -cc1 is -fno-rtti if we want to disable it, there's no problem in saying rtti is enabled if we're compiling C code, so we don't look at the input file type. addExceptionArgs now looks at the RTTIMode and warns that rtti is being enabled implicitly if targetting the PS4 and exceptions are on. It also errors out if, targetting the PS4, -fno-rtti was passed, and exceptions were turned on. SanitizerArgs now errors out if rtti was disabled explicitly and the vptr sanitizer was enabled implicitly, but just turns off vptr if rtti is disabled but -fsanitize=undefined was passed. Also fixed tests, removed duplicate name from addExceptionArgs comment, and added one or two surrounding lines when running clang-format. This changes test/Driver/fsanitize.c to make it not expect a warning when passed -fsanitize=undefined -fno-rtti, but expect vptr to not be on. Removed all users and definition of SanitizerArgs::sanitizesVptr(). Reviewers: samsonov Subscribers: llvm-commits, samsonov, rsmith Differential Revision: http://reviews.llvm.org/D7525 llvm-svn: 229801
2015-02-19 09:04:49 +08:00
// Make sure we only error/warn once, when trying to enable vptr and
// undefined and have -fno-rtti
[Sanitizers] Provide better diagnostic for sanitizers unsupported for target triple. Introduce ToolChain::getSupportedSanitizers() that would return the set of sanitizers available on given toolchain. By default, these are sanitizers which don't necessarily require runtime support and are not toolchain- or architecture-dependent. Sanitizers (ASan, DFSan, TSan, MSan etc.) which cannot function without runtime library are marked as supported only on platforms for which we actually build these runtimes. This would allow more fine-grained checks in the future: for instance, we have to restrict availability of -fsanitize=vptr to Mac OS 10.9+ (PR23539). Update test cases accrodingly: add tests for certain unsupported configurations, remove test cases for -fsanitize=vptr + PS4 integration, as we don't build the runtime for PS4 at the moment. This change was first submitted as r239953 and reverted in r239958. The problem was and still is in Darwin toolchains, which get the knowledge about target platform too late after initializaition, while now we require this information when ToolChain::getSanitizerArgs() is called. r240170 works around this issue. llvm-svn: 240179
2015-06-20 05:36:47 +08:00
// RUN: %clang -### -c -target x86_64-unknown-linux -fsanitize=undefined -fsanitize=vptr -fno-rtti %s 2>&1 | FileCheck -check-prefix=CHECK-SAN-ERROR -check-prefix=CHECK-OK %s
[ubsan] Have -fsanitize=vptr emit a null check if -fsanitize=null isn't available In r309007, I made -fsanitize=null a hard prerequisite for -fsanitize=vptr. I did not see the need for the two checks to have separate null checking logic for the same pointer. I expected the two checks to either always be enabled together, or to be mutually compatible. In the mailing list discussion re: r309007 it became clear that that isn't the case. If a codebase is -fsanitize=vptr clean but not -fsanitize=null clean, it's useful to have -fsanitize=vptr emit its own null check. That's what this patch does: with it, -fsanitize=vptr can be used without -fsanitize=null. Differential Revision: https://reviews.llvm.org/D36112 llvm-svn: 309846
2017-08-03 02:10:31 +08:00
// RUN: %clang -### -c -target x86_64-unknown-linux -fsanitize=vptr %s 2>&1 | FileCheck -check-prefix=CHECK-OK %s
// RUN: %clang -### -c -target x86_64-unknown-linux -fsanitize=vptr -frtti %s 2>&1 | FileCheck -check-prefix=CHECK-OK %s
// RUN: %clang -### -c -target x86_64-unknown-linux -fsanitize=vptr -fno-rtti %s 2>&1 | FileCheck -check-prefix=CHECK-SAN-ERROR %s
[Sanitizers] Provide better diagnostic for sanitizers unsupported for target triple. Introduce ToolChain::getSupportedSanitizers() that would return the set of sanitizers available on given toolchain. By default, these are sanitizers which don't necessarily require runtime support and are not toolchain- or architecture-dependent. Sanitizers (ASan, DFSan, TSan, MSan etc.) which cannot function without runtime library are marked as supported only on platforms for which we actually build these runtimes. This would allow more fine-grained checks in the future: for instance, we have to restrict availability of -fsanitize=vptr to Mac OS 10.9+ (PR23539). Update test cases accrodingly: add tests for certain unsupported configurations, remove test cases for -fsanitize=vptr + PS4 integration, as we don't build the runtime for PS4 at the moment. This change was first submitted as r239953 and reverted in r239958. The problem was and still is in Darwin toolchains, which get the knowledge about target platform too late after initializaition, while now we require this information when ToolChain::getSanitizerArgs() is called. r240170 works around this issue. llvm-svn: 240179
2015-06-20 05:36:47 +08:00
// RUN: %clang -### -c -target x86_64-unknown-linux -fsanitize=undefined %s 2>&1 | FileCheck -check-prefix=CHECK-OK %s
// RUN: %clang -### -c -target x86_64-unknown-linux -fsanitize=undefined -frtti %s 2>&1 | FileCheck -check-prefix=CHECK-OK %s
[ubsan] Have -fsanitize=vptr emit a null check if -fsanitize=null isn't available In r309007, I made -fsanitize=null a hard prerequisite for -fsanitize=vptr. I did not see the need for the two checks to have separate null checking logic for the same pointer. I expected the two checks to either always be enabled together, or to be mutually compatible. In the mailing list discussion re: r309007 it became clear that that isn't the case. If a codebase is -fsanitize=vptr clean but not -fsanitize=null clean, it's useful to have -fsanitize=vptr emit its own null check. That's what this patch does: with it, -fsanitize=vptr can be used without -fsanitize=null. Differential Revision: https://reviews.llvm.org/D36112 llvm-svn: 309846
2017-08-03 02:10:31 +08:00
// RUN: %clang -### -c -target x86_64-scei-ps4 -fsanitize=vptr %s 2>&1 | FileCheck -check-prefix=CHECK-SAN-WARN %s
Add some more PS4 driver settings related to rtti and exceptions. Summary: The PS4 defaults to -fno-rtti, and has to have rtti enabled when enabling exceptions. This commit makes clang add the -fno-rtti by default on the PS4, unless -frtti was passed in. It also diagnoses misuses for the PS4: - Exceptions need rtti. Warn and enable rtti if no rtti flag was passed, error if -fno-rtti was passed. I also added a more general warning for when -fno-rtti is the default (currently it's only on the PS4) and the vptr sanitizer is on. Fixed a few tests, due to different flag order when passing cc1 arguments. Reviewers: chandlerc Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D7250 llvm-svn: 227518
2015-01-30 07:56:43 +08:00
// Exceptions + no/default rtti
// RUN: %clang -### -c -target x86_64-unknown-unknown -fcxx-exceptions -fno-rtti %s 2>&1 | FileCheck -check-prefix=CHECK-OK %s
// RUN: %clang -### -c -target x86_64-unknown-unknown -fcxx-exceptions %s 2>&1 | FileCheck -check-prefix=CHECK-OK %s
Tweak behavior due to -fexceptions, in C++ mode, imply -fcxx-exceptions Added test llvm-svn: 227695
2015-02-01 07:05:51 +08:00
// In C++, -fexceptions implies -fcxx-exceptions
// RUN: %clang -x c++ -### -c -target x86_64-unknown-unknown -fexceptions -fno-rtti %s 2>&1 | FileCheck -check-prefix=CHECK-OK %s
// RUN: %clang -x c++ -### -c -target x86_64-unknown-unknown -fexceptions %s 2>&1 | FileCheck -check-prefix=CHECK-OK %s
Add some more PS4 driver settings related to rtti and exceptions. Summary: The PS4 defaults to -fno-rtti, and has to have rtti enabled when enabling exceptions. This commit makes clang add the -fno-rtti by default on the PS4, unless -frtti was passed in. It also diagnoses misuses for the PS4: - Exceptions need rtti. Warn and enable rtti if no rtti flag was passed, error if -fno-rtti was passed. I also added a more general warning for when -fno-rtti is the default (currently it's only on the PS4) and the vptr sanitizer is on. Fixed a few tests, due to different flag order when passing cc1 arguments. Reviewers: chandlerc Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D7250 llvm-svn: 227518
2015-01-30 07:56:43 +08:00
// -frtti + exceptions
// RUN: %clang -### -c -target x86_64-unknown-unknown -fcxx-exceptions -frtti %s 2>&1 | FileCheck -check-prefix=CHECK-OK %s
// -f{no-,}rtti/default
// RUN: %clang -### -c -target x86_64-scei-ps4 %s 2>&1 | FileCheck -check-prefix=CHECK-NO-RTTI %s
// RUN: %clang -### -c -target x86_64-unknown-unknown -frtti %s 2>&1 | FileCheck -check-prefix=CHECK-RTTI %s
// RUN: %clang -### -c -target x86_64-unknown-unknown -fno-rtti %s 2>&1 | FileCheck -check-prefix=CHECK-NO-RTTI %s
// RUN: %clang -### -c -target x86_64-unknown-unknown %s 2>&1 | FileCheck -check-prefix=CHECK-RTTI %s
Only add -fno-rtti if KernelOrKext or in C++ mode. llvm-svn: 232869
2015-03-21 07:51:15 +08:00
// CHECK-UNUSED: warning: argument unused during compilation: '-fcxx-exceptions'
PS4: Add tests for rtti/vptr-sanitizer interaction llvm-svn: 250515
2015-10-16 23:07:56 +08:00
// CHECK-SAN-WARN: implicitly disabling vptr sanitizer because rtti wasn't enabled
Add some more PS4 driver settings related to rtti and exceptions. Summary: The PS4 defaults to -fno-rtti, and has to have rtti enabled when enabling exceptions. This commit makes clang add the -fno-rtti by default on the PS4, unless -frtti was passed in. It also diagnoses misuses for the PS4: - Exceptions need rtti. Warn and enable rtti if no rtti flag was passed, error if -fno-rtti was passed. I also added a more general warning for when -fno-rtti is the default (currently it's only on the PS4) and the vptr sanitizer is on. Fixed a few tests, due to different flag order when passing cc1 arguments. Reviewers: chandlerc Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D7250 llvm-svn: 227518
2015-01-30 07:56:43 +08:00
// CHECK-SAN-ERROR: invalid argument '-fsanitize=vptr' not allowed with '-fno-rtti'
// CHECK-RTTI-NOT: "-fno-rtti"
Fixed some rtti-options tests. Certain tests in rtti-options.cpp are not really testing anything because they are testing for the absence of -frtti option to the cc1 process. Since the cc1 process does not take -frtti option, these tests are passing tautologically. The RTTI mode is enabled by default in cc1, and -fno-rtti disables it. Therefore the correct way to check for enabling of RTTI is to check for the absence of -fno-rtti to cc1, and the correct way to check for disabling of RTTI is to check for the presence of -fno-rtti to cc1. This patch fixes those tests. Differential Revision: https://reviews.llvm.org/D46836 llvm-svn: 332384
2018-05-16 02:28:42 +08:00
// CHECK-NO-RTTI: "-fno-rtti"
Add some more PS4 driver settings related to rtti and exceptions. Summary: The PS4 defaults to -fno-rtti, and has to have rtti enabled when enabling exceptions. This commit makes clang add the -fno-rtti by default on the PS4, unless -frtti was passed in. It also diagnoses misuses for the PS4: - Exceptions need rtti. Warn and enable rtti if no rtti flag was passed, error if -fno-rtti was passed. I also added a more general warning for when -fno-rtti is the default (currently it's only on the PS4) and the vptr sanitizer is on. Fixed a few tests, due to different flag order when passing cc1 arguments. Reviewers: chandlerc Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D7250 llvm-svn: 227518
2015-01-30 07:56:43 +08:00
// CHECK-OK-NOT: {{warning:|error:}}