maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Driver/clang_f_opts.c

127 lines
8.9 KiB
C
Raw Normal View History

Plumb through the -fsplit-stack option using the existing backend support. Caveat: Other than the existing segmented stacks support, no claims are made of this working. llvm-svn: 178744
2013-04-04 14:29:47 +08:00
// RUN: %clang -### -S -fasm -fblocks -fbuiltin -fno-math-errno -fcommon -fpascal-strings -fno-blocks -fno-builtin -fmath-errno -fno-common -fno-pascal-strings -fblocks -fbuiltin -fmath-errno -fcommon -fpascal-strings -fsplit-stack %s 2>&1 | FileCheck -check-prefix=CHECK-OPTIONS1 %s
Implement -fshort-enums (rdar://8490496). llvm-svn: 116020
2010-10-08 08:25:19 +08:00
// RUN: %clang -### -S -fasm -fblocks -fbuiltin -fno-math-errno -fcommon -fpascal-strings -fno-asm -fno-blocks -fno-builtin -fmath-errno -fno-common -fno-pascal-strings -fno-show-source-location -fshort-enums -fshort-wchar %s 2>&1 | FileCheck -check-prefix=CHECK-OPTIONS2 %s
Make using '-fshort-enums' an error until it is actually implemented (changes the ABI, so it is dangerous to not error out if we don't support it). Fixes <rdar://problem/7461006>. llvm-svn: 91191
2009-12-12 08:38:18 +08:00
Plumb through the -fsplit-stack option using the existing backend support. Caveat: Other than the existing segmented stacks support, no claims are made of this working. llvm-svn: 178744
2013-04-04 14:29:47 +08:00
// CHECK-OPTIONS1: -split-stacks
Daniel re-educated me about what Alias does and does not do. Turn that off for '-fasm' and explicitly map from that flag to -fgnu-keywords in the driver. Turn off the driver in the lexer test for this madness and add a test to the driver that the translation actually works. llvm-svn: 104428
2010-05-22 10:21:53 +08:00
// CHECK-OPTIONS1: -fgnu-keywords
Convert the remainder of this test case over to using FileCheck. llvm-svn: 91194
2009-12-12 08:42:52 +08:00
// CHECK-OPTIONS1: -fblocks
// CHECK-OPTIONS1: -fpascal-strings
Daniel re-educated me about what Alias does and does not do. Turn that off for '-fasm' and explicitly map from that flag to -fgnu-keywords in the driver. Turn off the driver in the lexer test for this madness and add a test to the driver that the translation actually works. llvm-svn: 104428
2010-05-22 10:21:53 +08:00
// CHECK_OPTIONS2: -fno-gnu-keywords
Use -fno-math-errno by default, and remove the IsMathErrnoDefault targethook, which is no longer being used. This fixes PR5971. llvm-svn: 92987
2010-01-08 10:20:44 +08:00
// CHECK-OPTIONS2: -fmath-errno
Convert the remainder of this test case over to using FileCheck. llvm-svn: 91194
2009-12-12 08:42:52 +08:00
// CHECK-OPTIONS2: -fno-builtin
Implement -fshort-enums (rdar://8490496). llvm-svn: 116020
2010-10-08 08:25:19 +08:00
// CHECK-OPTIONS2: -fshort-enums
Tests: Fix some bugs in clang_f_opts, options were out of order but it worked because it had two inputs, except on Win32 where /dev/null doesn't exist. llvm-svn: 91235
2009-12-13 10:00:23 +08:00
// CHECK-OPTIONS2: -fshort-wchar
Convert the remainder of this test case over to using FileCheck. llvm-svn: 91194
2009-12-12 08:42:52 +08:00
// CHECK-OPTIONS2: -fno-common
// CHECK-OPTIONS2: -fno-show-source-location
There were some frustrating problems with the implementation of -Wwrite-strings. First and foremost, once the positive form of the flag was passed, it could never be disabled by passing -Wno-write-strings. Also, the diagnostic engine couldn't in turn use -Wwrite-strings to control diagnostics (as GCC does) because it was essentially hijacked to drive the language semantics. Fix this by giving CC1 a clean '-fconst-strings' flag to enable const-qualified strings in C and ObjC compilations. Corresponding '-fno-const-strings' is also added. Then the driver is taught to introduce '-fconst-strings' in the CC1 command when '-Wwrite-strings' dominates. This entire flag is basically GCC-bug-compatibility driven, so we also match GCC's bug where '-w' doesn't actually disable -Wwrite-strings. I'm open to changing this though as it seems insane. llvm-svn: 130051
2011-04-23 14:30:43 +08:00
// RUN: %clang -### -S -Wwrite-strings %s 2>&1 | FileCheck -check-prefix=WRITE-STRINGS1 %s
// WRITE-STRINGS1: -fconst-strings
// RUN: %clang -### -S -Wwrite-strings -Wno-write-strings %s 2>&1 | FileCheck -check-prefix=WRITE-STRINGS2 %s
// WRITE-STRINGS2-NOT: -fconst-strings
// RUN: %clang -### -S -Wwrite-strings -w %s 2>&1 | FileCheck -check-prefix=WRITE-STRINGS3 %s
Tweak implementation of -Wwrite-strings to better match the behavior of current GCCs: * In C, as before, if the "warning flag" is enabled, warnings are produced by forcing string literals to have const-qualified types (the produced warnings are *not* -Wwrite-strings warnings). However, more recent GCCs (at least 4.4 onwards) now take -w into account here, so we now do the same. * In C++, this flag is entirely sane: it behaves just like any other warning flag. Stop triggering -fconst-strings here. This is a bit cleaner, but there's no real functionality change except in the case where -Xclang -fno-const-strings is also specified. llvm-svn: 190006
2013-09-05 06:50:31 +08:00
// WRITE-STRINGS3-NOT: -fconst-strings
Fix Clang's __DEPRECATED define to be controled by -Wdeprecated. This matches GCC behavior which libstdc++ uses to limit #warning-based messages about deprecation. The machinery involves threading this through a new '-fdeprecated-macro' flag for CC1. The flag defaults to "on", similarly to -Wdeprecated. We turn the flag off in the driver when the warning is turned off (modulo matching some GCC bugs). We record this as a language option, and key the preprocessor on the option when introducing the define. A separate flag rather than a '-D' flag allows us to properly represent the difference between C and C++ builds (only C++ receives the define), and it allows the specific behavior of following -Wdeprecated without potentially impacting the set of user-provided macro flags. llvm-svn: 130055
2011-04-23 17:27:53 +08:00
Move all of the logic for __DEPRECATED to the driver based on comments from dgregor. llvm-svn: 130066
2011-04-24 03:48:40 +08:00
// RUN: %clang -### -x c++ -c %s 2>&1 | FileCheck -check-prefix=DEPRECATED-ON-CHECK %s
// RUN: %clang -### -x c++ -c -Wdeprecated %s 2>&1 | FileCheck -check-prefix=DEPRECATED-ON-CHECK %s
// RUN: %clang -### -x c++ -c -Wno-deprecated %s 2>&1 | FileCheck -check-prefix=DEPRECATED-OFF-CHECK %s
// RUN: %clang -### -x c++ -c -Wno-deprecated -Wdeprecated %s 2>&1 | FileCheck -check-prefix=DEPRECATED-ON-CHECK %s
// RUN: %clang -### -x c++ -c -w %s 2>&1 | FileCheck -check-prefix=DEPRECATED-ON-CHECK %s
// RUN: %clang -### -c %s 2>&1 | FileCheck -check-prefix=DEPRECATED-OFF-CHECK %s
// RUN: %clang -### -c -Wdeprecated %s 2>&1 | FileCheck -check-prefix=DEPRECATED-OFF-CHECK %s
// DEPRECATED-ON-CHECK: -fdeprecated-macro
// DEPRECATED-OFF-CHECK-NOT: -fdeprecated-macro
Add -ffp-contract = { fast | on | off } command line option support. This flag sets the 'fp-contract' mode, which controls the formation of fused floating point operations. Available modes are: - Fast: Form fused operations anywhere. - On: Form fused operations where allowed by FP_CONTRACT. This is the default mode. - Off: Don't form fused operations (in future this may be relaxed to forming fused operations where it can be proved that the result won't be affected). Currently clang doesn't support the FP_CONTRACT pragma, so the 'On' and 'Off' modes are equivalent. llvm-svn: 159794
2012-07-06 08:59:19 +08:00
// RUN: %clang -### -S -ffp-contract=fast %s 2>&1 | FileCheck -check-prefix=FP-CONTRACT-FAST-CHECK %s
// RUN: %clang -### -S -ffast-math %s 2>&1 | FileCheck -check-prefix=FP-CONTRACT-FAST-CHECK %s
// RUN: %clang -### -S -ffp-contract=off %s 2>&1 | FileCheck -check-prefix=FP-CONTRACT-OFF-CHECK %s
// FP-CONTRACT-FAST-CHECK: -ffp-contract=fast
// FP-CONTRACT-OFF-CHECK: -ffp-contract=off
Add a new flag, -fms-inline-asm, that enables the output of MS-style inline assembly. By default, we don't emit IR for MS-style inline assembly (see r158833 as to why). This is strictly for testing purposes and should not be enabled with the expectation that things will work. This is a temporary flag and will be removed once MS-style inline assembly is fully supported. llvm-svn: 160573
2012-07-21 05:20:33 +08:00
The only useful loop unrolling flag to give realistically is '-fno-unroll-loops'. The option to the backend is even called 'DisableUnrollLoops'. This is precisely the form that Clang *didn't* support. We didn't recognize the flag, we didn't pass it to the CC1 layer, and even if we did we wouldn't use it. Clang only inspected the positive form of the flag, and only did so to enable loop unrolling when the optimization level wasn't high enough. This only occurs for an optimization level that even has a chance of running the loop unroller when optimizing for size. This commit wires up the 'no' variant, and switches the code to actually follow the standard flag pattern of using the last flag and allowing a flag in either direction to override the default. I think this is still wrong. I don't know why we disable the loop unroller entirely *from Clang* when optimizing for size, as the loop unrolling pass *already has special logic* for the case where the function is attributed as optimized for size! We should really be trusting that. Maybe in a follow-up patch, I don't really want to change behavior here. llvm-svn: 187969
2013-08-08 16:34:35 +08:00
// RUN: %clang -### -S -funroll-loops %s 2>&1 | FileCheck -check-prefix=CHECK-UNROLL-LOOPS %s
// RUN: %clang -### -S -fno-unroll-loops %s 2>&1 | FileCheck -check-prefix=CHECK-NO-UNROLL-LOOPS %s
// RUN: %clang -### -S -fno-unroll-loops -funroll-loops %s 2>&1 | FileCheck -check-prefix=CHECK-UNROLL-LOOPS %s
// RUN: %clang -### -S -funroll-loops -fno-unroll-loops %s 2>&1 | FileCheck -check-prefix=CHECK-NO-UNROLL-LOOPS %s
// CHECK-UNROLL-LOOPS: "-funroll-loops"
// CHECK-NO-UNROLL-LOOPS: "-fno-unroll-loops"
[driver] Add the -fvectorize flag to enable the loop vectorization passes. rdar://12839978 llvm-svn: 169885
2012-12-12 01:12:28 +08:00
// RUN: %clang -### -S -fvectorize %s 2>&1 | FileCheck -check-prefix=CHECK-VECTORIZE %s
// RUN: %clang -### -S -fno-vectorize -fvectorize %s 2>&1 | FileCheck -check-prefix=CHECK-VECTORIZE %s
// RUN: %clang -### -S -fno-vectorize %s 2>&1 | FileCheck -check-prefix=CHECK-NO-VECTORIZE %s
// RUN: %clang -### -S -fvectorize -fno-vectorize %s 2>&1 | FileCheck -check-prefix=CHECK-NO-VECTORIZE %s
[driver] Add the -ftree-vectorize flag as a alias of -fvectorize to maintain compatibility with gcc. rdar://12839978 llvm-svn: 169888
2012-12-12 01:46:33 +08:00
// RUN: %clang -### -S -ftree-vectorize %s 2>&1 | FileCheck -check-prefix=CHECK-VECTORIZE %s
Fix the fvectorize testcase llvm-svn: 170469
2012-12-19 07:08:58 +08:00
// RUN: %clang -### -S -fno-tree-vectorize -fvectorize %s 2>&1 | FileCheck -check-prefix=CHECK-VECTORIZE %s
// RUN: %clang -### -S -fno-tree-vectorize %s 2>&1 | FileCheck -check-prefix=CHECK-NO-VECTORIZE %s
[driver] Add the -ftree-vectorize flag as a alias of -fvectorize to maintain compatibility with gcc. rdar://12839978 llvm-svn: 169888
2012-12-12 01:46:33 +08:00
// RUN: %clang -### -S -ftree-vectorize -fno-vectorize %s 2>&1 | FileCheck -check-prefix=CHECK-NO-VECTORIZE %s
Move logic to enable the vectorizer to clang We used to decide whether to really vectorize depending on the optimization level in PassManagerBuilder. This patch moves this decision to the clang driver. We look at the optimization level and whether the f(no-)vectorize is set and decide whether to vectorize. This allows us to simplify the logic in PassManagerBuilder to just a check for whether the vectorizer should run or not. We now do the right thing for: $ clang -O1 -fvectorize $ clang -fno-vectorize -O3 llvm-svn: 188280
2013-08-13 23:46:23 +08:00
// RUN: %clang -### -S -O %s 2>&1 | FileCheck -check-prefix=CHECK-VECTORIZE %s
// RUN: %clang -### -S -O2 %s 2>&1 | FileCheck -check-prefix=CHECK-VECTORIZE %s
// RUN: %clang -### -S -Os %s 2>&1 | FileCheck -check-prefix=CHECK-VECTORIZE %s
// RUN: %clang -### -S -O3 %s 2>&1 | FileCheck -check-prefix=CHECK-VECTORIZE %s
// RUN: %clang -### -S -fno-vectorize -O3 %s 2>&1 | FileCheck -check-prefix=CHECK-VECTORIZE %s
// RUN: %clang -### -S -O1 -fvectorize %s 2>&1 | FileCheck -check-prefix=CHECK-VECTORIZE %s
// RUN: %clang -### -S -Ofast %s 2>&1 | FileCheck -check-prefix=CHECK-VECTORIZE %s
// RUN: %clang -### -S %s 2>&1 | FileCheck -check-prefix=CHECK-NO-VECTORIZE %s
// RUN: %clang -### -S -O0 %s 2>&1 | FileCheck -check-prefix=CHECK-NO-VECTORIZE %s
// RUN: %clang -### -S -O1 %s 2>&1 | FileCheck -check-prefix=CHECK-NO-VECTORIZE %s
// RUN: %clang -### -S -Oz %s 2>&1 | FileCheck -check-prefix=CHECK-NO-VECTORIZE %s
[driver] Add the -fvectorize flag to enable the loop vectorization passes. rdar://12839978 llvm-svn: 169885
2012-12-12 01:12:28 +08:00
// CHECK-VECTORIZE: "-vectorize-loops"
// CHECK-NO-VECTORIZE-NOT: "-vectorize-loops"
Add -fslp-vectorize to enable bb-vectorize Add -fslp-vectorize (with -ftree-slp-vectorize as an alias for gcc compatibility) to provide a way to enable the basic-block vectorization pass. This uses the same acronym as gcc, superword-level parallelism (SLP), also common in the literature, to refer to basic-block vectorization. Nadav suggested this as a follow-up to the adding of -fvectorize. llvm-svn: 169909
2012-12-12 03:59:32 +08:00
// RUN: %clang -### -S -fslp-vectorize %s 2>&1 | FileCheck -check-prefix=CHECK-SLP-VECTORIZE %s
// RUN: %clang -### -S -fno-slp-vectorize -fslp-vectorize %s 2>&1 | FileCheck -check-prefix=CHECK-SLP-VECTORIZE %s
// RUN: %clang -### -S -fno-slp-vectorize %s 2>&1 | FileCheck -check-prefix=CHECK-NO-SLP-VECTORIZE %s
// RUN: %clang -### -S -fslp-vectorize -fno-slp-vectorize %s 2>&1 | FileCheck -check-prefix=CHECK-NO-SLP-VECTORIZE %s
// RUN: %clang -### -S -ftree-slp-vectorize %s 2>&1 | FileCheck -check-prefix=CHECK-SLP-VECTORIZE %s
Fix the fvectorize testcase llvm-svn: 170469
2012-12-19 07:08:58 +08:00
// RUN: %clang -### -S -fno-tree-slp-vectorize -fslp-vectorize %s 2>&1 | FileCheck -check-prefix=CHECK-SLP-VECTORIZE %s
// RUN: %clang -### -S -fno-tree-slp-vectorize %s 2>&1 | FileCheck -check-prefix=CHECK-NO-SLP-VECTORIZE %s
Add -fslp-vectorize to enable bb-vectorize Add -fslp-vectorize (with -ftree-slp-vectorize as an alias for gcc compatibility) to provide a way to enable the basic-block vectorization pass. This uses the same acronym as gcc, superword-level parallelism (SLP), also common in the literature, to refer to basic-block vectorization. Nadav suggested this as a follow-up to the adding of -fvectorize. llvm-svn: 169909
2012-12-12 03:59:32 +08:00
// RUN: %clang -### -S -ftree-slp-vectorize -fno-slp-vectorize %s 2>&1 | FileCheck -check-prefix=CHECK-NO-SLP-VECTORIZE %s
Rename the slp-vectorizer clang/llvm flags. No functionality change. llvm-svn: 179506
2013-04-15 12:57:18 +08:00
// CHECK-SLP-VECTORIZE: "-vectorize-slp"
// CHECK-NO-SLP-VECTORIZE-NOT: "-vectorize-slp"
Accept and ignore the -fextended-identifiers option. This was GCC's option to turn on UCN support, which we always have on now in C99 and C++ modes. Additionally, mark the -fno-extended-identifiers option as unsupported, since we don't support disabling UCNs in C99 and C++ modes. PR11538 llvm-svn: 174530
2013-02-07 02:15:40 +08:00
Add a new flag -vectorize-slp-aggressive to enable Hals BB vectorizer. llvm-svn: 179507
2013-04-15 13:38:41 +08:00
// RUN: %clang -### -S -fslp-vectorize-aggressive %s 2>&1 | FileCheck -check-prefix=CHECK-SLP-VECTORIZE-AGG %s
// RUN: %clang -### -S -fno-slp-vectorize-aggressive -fslp-vectorize-aggressive %s 2>&1 | FileCheck -check-prefix=CHECK-SLP-VECTORIZE-AGG %s
// RUN: %clang -### -S -fno-slp-vectorize-aggressive %s 2>&1 | FileCheck -check-prefix=CHECK-NO-SLP-VECTORIZE-AGG %s
// RUN: %clang -### -S -fslp-vectorize-aggressive -fno-slp-vectorize-aggressive %s 2>&1 | FileCheck -check-prefix=CHECK-NO-SLP-VECTORIZE-AGG %s
// CHECK-SLP-VECTORIZE-AGG: "-vectorize-slp-aggressive"
// CHECK-NO-SLP-VECTORIZE-AGG-NOT: "-vectorize-slp-aggressive"
Accept and ignore the -fextended-identifiers option. This was GCC's option to turn on UCN support, which we always have on now in C99 and C++ modes. Additionally, mark the -fno-extended-identifiers option as unsupported, since we don't support disabling UCNs in C99 and C++ modes. PR11538 llvm-svn: 174530
2013-02-07 02:15:40 +08:00
// RUN: %clang -### -S -fextended-identifiers %s 2>&1 | FileCheck -check-prefix=CHECK-EXTENDED-IDENTIFIERS %s
// RUN: %clang -### -S -fno-extended-identifiers %s 2>&1 | FileCheck -check-prefix=CHECK-NO-EXTENDED-IDENTIFIERS %s
// CHECK-EXTENDED-IDENTIFIERS: "-cc1"
// CHECK-EXTENDED-IDENTIFIERS-NOT: "-fextended-identifiers"
// CHECK-NO-EXTENDED-IDENTIFIERS: error: unsupported option '-fno-extended-identifiers'
Make -m[no-]pascal-strings an alias of -f[no]pascal-strings in the .td file This way we don't have to translate it manually in Clang::ConstructJob. Differential Revision: http://llvm-reviews.chandlerc.com/D1249 llvm-svn: 187547
2013-08-01 07:39:13 +08:00
// RUN: %clang -### -S -fno-pascal-strings -mpascal-strings %s 2>&1 | FileCheck -check-prefix=CHECK-M-PASCAL-STRINGS %s
// CHECK-M-PASCAL-STRINGS: "-fpascal-strings"
// RUN: %clang -### -S -fpascal-strings -mno-pascal-strings %s 2>&1 | FileCheck -check-prefix=CHECK-NO-M-PASCAL-STRINGS %s
// CHECK-NO-M-PASCAL-STRINGS-NOT: "-fpascal-strings"
Don't imply -flto with -O4. We now saturate at -O3. llvm-svn: 189149
2013-08-24 05:49:00 +08:00
// RUN: %clang -### -S -O4 %s 2>&1 | FileCheck -check-prefix=CHECK-MAX-O %s
Warn that -O4 is the same as -O3. We error on -O5 and higher. While it is tempting to do the same for -O4, I agree with Jordan Rose: we should warn for a release at least first. llvm-svn: 189369
2013-08-28 00:58:15 +08:00
// CHECK-MAX-O: warning: -O4 is equivalent to -O3
Don't imply -flto with -O4. We now saturate at -O3. llvm-svn: 189149
2013-08-24 05:49:00 +08:00
// CHECK-MAX-O: -O3
Ignore some -f options that are supported by gcc. It is possible that we should say some of these are unsupported, but this is not any worse than the old behavior of ignoring all unknown -f options. llvm-svn: 191429
2013-09-26 21:10:14 +08:00
// Test that we don't error on these.
Remove fno_builtin_strcat and fno_builtin_strcpy. They are already handled by the generic fno_bultin_, which also avoids unused warnings. llvm-svn: 191437
2013-09-27 00:45:27 +08:00
// RUN: %clang -### -S -Werror \
Ignore some -f options that are supported by gcc. It is possible that we should say some of these are unsupported, but this is not any worse than the old behavior of ignoring all unknown -f options. llvm-svn: 191429
2013-09-26 21:10:14 +08:00
// RUN: -falign-functions -falign-functions=2 -fno-align-functions \
// RUN: -fasynchronous-unwind-tables -fno-asynchronous-unwind-tables \
// RUN: -fbuiltin -fno-builtin \
// RUN: -ffloat-store -fno-float-store \
// RUN: -feliminate-unused-debug-types -fno-eliminate-unused-debug-types \
// RUN: -fgcse -fno-gcse \
// RUN: -fident -fno-ident \
// RUN: -fivopts -fno-ivopts \
// RUN: -fnon-call-exceptions -fno-non-call-exceptions \
// RUN: -fpermissive -fno-permissive \
// RUN: -fprefetch-loop-arrays -fno-prefetch-loop-arrays \
// RUN: -fprofile-correction -fno-profile-correction \
// RUN: -fprofile-dir=bar \
// RUN: -fprofile-use -fprofile-use=zed -fno-profile-use \
// RUN: -fprofile-values -fno-profile-values \
// RUN: -frounding-math -fno-rounding-math \
// RUN: -fsee -fno-see \
// RUN: -ftracer -fno-tracer \
// RUN: -funroll-all-loops -fno-unroll-all-loops \
Ignore unknown -fno-builtin-*. This matches gcc's behavior. llvm-svn: 191434
2013-09-27 00:15:40 +08:00
// RUN: -fno-builtin-foobar \
Remove fno_builtin_strcat and fno_builtin_strcpy. They are already handled by the generic fno_bultin_, which also avoids unused warnings. llvm-svn: 191437
2013-09-27 00:45:27 +08:00
// RUN: -fno-builtin-strcat -fno-builtin-strcpy \
Ignore some -f options that are supported by gcc. It is possible that we should say some of these are unsupported, but this is not any worse than the old behavior of ignoring all unknown -f options. llvm-svn: 191429
2013-09-26 21:10:14 +08:00
// RUN: %s