InlineCost's isInlineViable() is changed to return InlineResult
instead of bool. This provides messages for failure reasons and
allows to get more specific messages for cases where callsites
are not viable for inlining.
Reviewed By: xbolva00, anemet
Differential Revision: https://reviews.llvm.org/D57089
llvm-svn: 352849
It is intended to disable _all_ warnings, even those upgraded to
errors via `-Werror=warningname` or `#pragma clang diagnostic error'
Fixes: https://llvm.org/PR38231
Differential Revision: https://reviews.llvm.org/D53199
llvm-svn: 352535
Summary:
When mounting LLVM source into a windows container in read-only mode, certain tests fail. Ideally, we want all these tests to pass so that developers can mount the same source folder into multiple (windows) containers simultaneously, allowing them to build/test the same source code using various different configurations simultaneously.
**Fix**: I've found that when attempting to open a file for writing on windows, if you don't have the correct permissions (trying to open a file for writing in a read-only folder), you get [Access is denied](https://support.microsoft.com/en-us/help/2623670/access-denied-or-other-errors-when-you-access-or-work-with-files-and-f). In llvm, we map this error message to a linux based error, see: https://github.com/llvm-mirror/llvm/blob/master/lib/Support/ErrorHandling.cpp
This is why we see "Permission denied" in our output as opposed to the expected "No such file or directory", thus causing the tests to fail.
I've changed the test locally to instead point to the root drive so that they can successfully bypass the Access is denied error when LLVM is mounted in as a read-only directory. This way, the test operate exactly the same, but we can get around the windows-complications of what error to expect in a read-only directory.
Patch By: justice_adams
Reviewers: rsmith, zturner, MatzeB, stella.stamenova
Reviewed By: stella.stamenova
Subscribers: ormris, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D50563
llvm-svn: 352252
This patch includes logic for constant expression evaluation of fixed point additions.
Differential Revision: https://reviews.llvm.org/D55868
llvm-svn: 351593
This patch covers subtraction between fixed point types and other fixed point
types or integers, using the conversion rules described in 4.1.4 of N1169.
Differential Revision: https://reviews.llvm.org/D55844
llvm-svn: 351371
This patch covers addition between fixed point types and other fixed point
types or integers, using the conversion rules described in 4.1.4 of N1169.
Usual arithmetic rules do not apply to binary operations when one of the
operands is a fixed point type, and the result of the operation must be
calculated with the full precision of the operands, so we should not perform
any casting to a common type.
This patch does not include constant expression evaluation for addition of
fixed point types. That will be addressed in another patch since I think this
one is already big enough.
Differential Revision: https://reviews.llvm.org/D53738
llvm-svn: 351364
-plugin already prints an error if the name of an unknown plugin is passed.
-add-plugin used to silently ignore that, now it errors too.
Differential Revision: https://reviews.llvm.org/D56273
llvm-svn: 350340
pass in the -target-sdk-version to the compiler and backend
This commit adds support for reading the SDKSettings.json file in the Darwin
driver. This file is used by the driver to determine the SDK's version, and it
uses that information to pass it down to the compiler using the new
-target-sdk-version= option. This option is then used to set the appropriate
SDK Version module metadata introduced in r349119.
Note: I had to adjust the two ast tests as the SDKROOT environment variable
on macOS caused SDK version to be picked up for the compilation of source file
but not the AST.
rdar://45774000
Differential Revision: https://reviews.llvm.org/D55673
llvm-svn: 349380
This patch adds the noderef attribute in clang and checks for dereferences of
types that have this attribute. This attribute is currently used by sparse and
would like to be ported to clang.
Differential Revision: https://reviews.llvm.org/D49511
llvm-svn: 348442
This moves everything primarily testing the functionality of -ast-dump and -ast-print into their own directory, rather than leaving the tests spread around the testing directory.
llvm-svn: 348017
Summary:
- Added names for some emitted values (such as "tobool" for
the result of a cast to boolean).
- Replaced explicit IRBuilder request for doing sext/zext/trunc
by using CreateIntCast instead.
- Simplify code for emitting satuation into one if-statement
for clamping to max, and one if-statement for clamping to min.
Reviewers: leonardchan, ebevhan
Reviewed By: leonardchan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D53707
llvm-svn: 345398
This patch is a part of https://reviews.llvm.org/D48456 in an attempt to split
the casting logic up into smaller patches. This contains the code for casting
from fixed point types to boolean types.
Differential Revision: https://reviews.llvm.org/D53308
llvm-svn: 345063
This patch is a part of https://reviews.llvm.org/D48456 in an attempt to
split them up. This contains the code for casting between fixed point types
and other fixed point types.
The method for converting between fixed point types is based off the convert()
method in APFixedPoint.
Differential Revision: https://reviews.llvm.org/D50616
llvm-svn: 344530
This adds a preprocessor callback for the `__has_include` and
`__has_include_next` directives.
Successful checking for the presence of a header should add it to the list of
header dependencies so this overrides the callback in the dependency scanner.
Patch by Pete Cooper with some additions by me.
rdar://problem/39545636
Differential Revision: https://reviews.llvm.org/D30882
llvm-svn: 342517
LLVM triple normalization is handling "unknown" and empty components
differently; for example given "x86_64-unknown-linux-gnu" and
"x86_64-linux-gnu" which should be equivalent, triple normalization
returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's
config.sub returns "x86_64-unknown-linux-gnu" for both
"x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the
triple normalization to behave the same way, replacing empty triple
components with "unknown".
This addresses PR37129.
Differential Revision: https://reviews.llvm.org/D50219
llvm-svn: 339294
This patch proposes an abstract type that represents fixed point numbers, similar to APInt or APSInt that was discussed in https://reviews.llvm.org/D48456#inline-425585. This type holds a value, scale, and saturation and is meant to perform intermediate calculations on constant fixed point values.
Currently this class is used as a way for handling the conversions between fixed point numbers with different sizes and radixes. For example, if I'm casting from a signed _Accum to a saturated unsigned short _Accum, I will need to check the value of the signed _Accum to see if it fits into the short _Accum which involves getting and comparing against the max/min values of the short _Accum. The FixedPointNumber class currently handles the radix shifting and extension when converting to a signed _Accum.
Differential Revision: https://reviews.llvm.org/D48661
llvm-svn: 339028
- Print negative numbers correctly
- Handle APInts of different sizes
- Add formal unit tests for FixedPointValueToString
- Add tests for checking correct printing when padding is set
- Restrict to printing in radix 10 since that's all we need for now
Differential Revision: https://reviews.llvm.org/D49945
llvm-svn: 339026
Summary:
Optimization remark format is slightly changed by LLVM patch D49412.
Two tests are fixed with expected messages changed.
Frankly speaking I have not tested this change yet. I will test when manage to setup the project.
Reviewers: xbolva00
Reviewed By: xbolva00
Subscribers: mehdi_amini, eraman, steven_wu, dexonsmith
Differential Revision: https://reviews.llvm.org/D50241
llvm-svn: 338971
This addresses a bug brought up in https://bugs.llvm.org/show_bug.cgi?id=38161 where integer literals could be treated as fixed point types and throw errors related to fixed point types when the 'k' or 'r' suffix used. The fix also addresses the second issue brought up with the assertion by not treating integers as fixed point types in the first place.
Integers that have suffixes 'k' and 'r' now throw the error `invalid suffix 'k/r' on integer constant`.
A few more tests were also added to ensure that fixed point types, and any errors/warnings related to them, are limited to C for now.
Prior discussion also at https://reviews.llvm.org/D46915.
Differential Revision: https://reviews.llvm.org/D49327
llvm-svn: 337289
- Rename the `-fsame-fbits` flag to `-fpadding-on-unsigned-fixed-point`
- Move the flag from a driver option to a cc1 option
- Rename the `SameFBits` member in TargetInfo to `PaddingOnUnsignedFixedPoint`
- Updated descriptions
Differential Revision: https://reviews.llvm.org/D48727
llvm-svn: 335993
The new C++ stdlib warning added in r335081 gets
triggered when compiling an assembly file with -x assembler-with-cpp.
This commit ensures that the C++ stdlib is not included when compiling assembly.
In general, it's not really useful to include the C++ stdlib search path when
compiling assembly source.
rdar://41359632
Differential Revision: https://reviews.llvm.org/D48736
llvm-svn: 335940
This diff includes the logic for setting the precision bits for each primary fixed point type in the target info and logic for initializing a fixed point literal.
Fixed point literals are declared using the suffixes
```
hr: short _Fract
uhr: unsigned short _Fract
r: _Fract
ur: unsigned _Fract
lr: long _Fract
ulr: unsigned long _Fract
hk: short _Accum
uhk: unsigned short _Accum
k: _Accum
uk: unsigned _Accum
```
Errors are also thrown for illegal literal values
```
unsigned short _Accum u_short_accum = 256.0uhk; // expected-error{{the integral part of this literal is too large for this unsigned _Accum type}}
```
Differential Revision: https://reviews.llvm.org/D46915
llvm-svn: 335148
The recommit ensures that the tests that failed on bots don't trigger the warning.
Xcode 10 removes support for libstdc++, but the users just get a confusing
include not file warning when including an STL header (when building for iOS6
which uses libstdc++ by default for example).
This patch adds a new warning that lets the user know that the libstdc++ include
path was not found to ensure that the user is more aware of why the error occurs.
rdar://40830462
Differential Revision: https://reviews.llvm.org/D48297
llvm-svn: 335081
Xcode 10 removes support for libstdc++, but the users just get a confusing
include not file warning when including an STL header (when building for iOS6
which uses libstdc++ by default for example).
This patch adds a new warning that lets the user know that the libstdc++ include
path was not found to ensure that the user is more aware of why the error occurs.
rdar://40830462
Differential Revision: https://reviews.llvm.org/D48297
llvm-svn: 335063
This diff includes changes for the remaining _Fract and _Sat fixed point types.
```
signed short _Fract s_short_fract;
signed _Fract s_fract;
signed long _Fract s_long_fract;
unsigned short _Fract u_short_fract;
unsigned _Fract u_fract;
unsigned long _Fract u_long_fract;
// Aliased fixed point types
short _Accum short_accum;
_Accum accum;
long _Accum long_accum;
short _Fract short_fract;
_Fract fract;
long _Fract long_fract;
// Saturated fixed point types
_Sat signed short _Accum sat_s_short_accum;
_Sat signed _Accum sat_s_accum;
_Sat signed long _Accum sat_s_long_accum;
_Sat unsigned short _Accum sat_u_short_accum;
_Sat unsigned _Accum sat_u_accum;
_Sat unsigned long _Accum sat_u_long_accum;
_Sat signed short _Fract sat_s_short_fract;
_Sat signed _Fract sat_s_fract;
_Sat signed long _Fract sat_s_long_fract;
_Sat unsigned short _Fract sat_u_short_fract;
_Sat unsigned _Fract sat_u_fract;
_Sat unsigned long _Fract sat_u_long_fract;
// Aliased saturated fixed point types
_Sat short _Accum sat_short_accum;
_Sat _Accum sat_accum;
_Sat long _Accum sat_long_accum;
_Sat short _Fract sat_short_fract;
_Sat _Fract sat_fract;
_Sat long _Fract sat_long_fract;
```
This diff only allows for declaration of these fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches.
Differential Revision: https://reviews.llvm.org/D46911
llvm-svn: 334718
The windows-msvc target is used for MSVC ABI compatibility, including
the exceptions model. It doesn't make sense to pair a windows-msvc
target with a non-MSVC exception model. This would previously cause an
assertion failure; explicitly error out for it in the frontend instead.
This also allows us to reduce the matrix of target/exception models a
bit (see the modified tests), and we can possibly simplify some of the
personality code in a follow-up.
Differential Revision: https://reviews.llvm.org/D47853
llvm-svn: 334243
// Primary fixed point types
signed short _Accum s_short_accum;
signed _Accum s_accum;
signed long _Accum s_long_accum;
unsigned short _Accum u_short_accum;
unsigned _Accum u_accum;
unsigned long _Accum u_long_accum;
// Aliased fixed point types
short _Accum short_accum;
_Accum accum;
long _Accum long_accum;
This diff only allows for declaration of the fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches. The saturated versions of these types and the equivalent _Fract types will also be added in future patches.
The tests included are for asserting that we can declare these types.
Fixed the test that was failing by not checking for dso_local on some
targets.
Differential Revision: https://reviews.llvm.org/D46084
llvm-svn: 333923
```
// Primary fixed point types
signed short _Accum s_short_accum;
signed _Accum s_accum;
signed long _Accum s_long_accum;
unsigned short _Accum u_short_accum;
unsigned _Accum u_accum;
unsigned long _Accum u_long_accum;
// Aliased fixed point types
short _Accum short_accum;
_Accum accum;
long _Accum long_accum;
```
This diff only allows for declaration of the fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches. The saturated versions of these types and the equivalent `_Fract` types will also be added in future patches.
The tests included are for asserting that we can declare these types.
Differential Revision: https://reviews.llvm.org/D46084
llvm-svn: 333814
Add the ability to dump compiler option-related information to a JSON file via the -compiler-options-dump option. Specifically, it dumps the features/extensions lists -- however, this output could be extended to other information should it be useful. In order to support features and extensions, I moved them into a .def file so that we could build the various lists we care about from them without a significant increase in maintenance burden.
llvm-svn: 333653
Summary:
This commit fixes a bug where passing extra dependency entries
(using -fdepfile-entry) would result in -MP incorrectly emitting
a phony target for the input file, and no phony target for the
first extra dependency.
The extra dependencies are added first to the filename vector in
DFGImpl. That clashed with the emission of the phony targets, as
the code assumed that the first index always correspond to the
input file.
Reviewers: rsmith, pcc, krasin, bruno, vsapsai
Reviewed By: vsapsai
Subscribers: vsapsai, bruno, cfe-commits
Differential Revision: https://reviews.llvm.org/D44568
llvm-svn: 333413
Currently LLVM CFI tries to use an implicit blacklist file, currently
in /usr/lib64/clang/<version>/share. If the file is not there, LLVM
happily continues, which causes CFI to add checks to files/functions
that are known to fail, generating binaries that fail. This CL causes
LLVM to die (I hope) if it can't find these implicit blacklist files.
Patch by Caroline Tice!
Differential Revision: https://reviews.llvm.org/D46403
llvm-svn: 331674
This replicates 'cl.exe' behavior and allows for both preprocessor output and
dependency information to be extraced with a single compiler invocation.
This is especially useful for compiler caching with tools like Mozilla's sccache.
See: https://github.com/mozilla/sccache/issues/246
Patch By: fxb
Differential Revision: https://reviews.llvm.org/D46394
llvm-svn: 331533
It's possible for a header to be a symlink to another header. In this
case both will be represented by clang::FileEntry with the same UID and
they'll use the same clang::HeaderFileInfo.
If you include both headers and use some single-inclusion mechanism
like a header guard or #import, one header will get a FileChanged
callback, and another FileSkipped.
So that we get an accurate dependency file, we therefore need to also
implement the FileSkipped callback in dependency scanning.
Patch by Pete Cooper.
Reviewers: bruno, pete
Reviewed By: bruno
Subscribers: cfe-commits, jkorous, vsapsai
Differential Revision: https://reviews.llvm.org/D30881
llvm-svn: 331319
Some buildbots seems to have problems with the CHECKs in
test/Frontend/ftime-report-template-decl.cpp.
I this the problem is that the order in which timers are printed
is based on consumed wall time. So there is no guarantee in which
order the timers are printed.
This patch uses CHECK-DAG instead of CHECK to make the test
case less sensitive to the actual time used by the different
passes.
The (sometimes) failing test cases where introduced in trunk@330571.
llvm-svn: 330622
`__has_include_next` requires correct DirectoryLookup for being
evaluated correctly. We were using Preprocessor::GetCurDirLookup() but
we were calling it after the preprocessor finished its work. And in this
case CurDirLookup is always nullptr which makes `__has_include_next`
behave as `__has_include`.
Fix by storing and using CurDirLookup when preprocessor enters a file,
not when we rewrite the includes.
rdar://problem/36305026
Reviewers: bkramer
Reviewed By: bkramer
Subscribers: jkorous-apple, cfe-commits
Differential Revision: https://reviews.llvm.org/D45603
llvm-svn: 330041
It means the same thing as -mllvm; there isn't any reason to have two
options which do the same thing.
Differential Revision: https://reviews.llvm.org/D45109
llvm-svn: 329965
The current support of the feature produces only 2 lines in report:
-Some general Code Generation Time;
-Total time of Backend Consumer actions.
This patch extends Clang time report with new lines related to Preprocessor, Include Filea Search, Parsing, etc.
Differential Revision: https://reviews.llvm.org/D43578
llvm-svn: 329684
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
This reverts commit r324500.
The bots found two failures:
ThreadSanitizer-x86_64 :: Linux/pie_no_aslr.cc
ThreadSanitizer-x86_64 :: pie_test.cc
when using gold. The issue is a limitation in gold when building pie
binaries. I will investigate how to work around it.
llvm-svn: 324505
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: 324500
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: 324107
Summary:
Both MS and PS4 targets are capable of recognizing the
existence of: #pragma region, #pragma endregion.
Since this pragma is only a hint for certain editors, and has no logic,
it seems helpful to permit this pragma in all cases, not just MS compatibility mode.
Reviewers: rnk, rsmith, majnemer
Reviewed By: majnemer
Subscribers: Quuxplusone, probinson, majnemer, cfe-commits
Differential Revision: https://reviews.llvm.org/D42248
llvm-svn: 323577
Summary:
Depends on https://reviews.llvm.org/D41732.
Utilities such as `opt`, when invoked with arguments that are very
nearly spelled correctly, suggest the correctly spelled options:
```
bin/opt -hel
opt: Unknown command line argument '-hel'. Try: 'bin/opt -help'
opt: Did you mean '-help'?
```
Clang, on the other hand, prior to this commit, does not:
```
bin/clang -hel
clang-6.0: error: unknown argument: '-hel'
```
This commit makes use of the new libLLVMOption API from
https://reviews.llvm.org/D41732 in order to provide correct suggestions:
```
bin/clang -hel
clang-6.0: error: unknown argument: '-hel', did you mean '-help'?
```
Test Plan: `check-clang`
Reviewers: yamaguchi, v.g.vassilev, teemperor, ruiu, bruno
Reviewed By: bruno
Subscribers: bruno, jroelofs, cfe-commits
Differential Revision: https://reviews.llvm.org/D41733
llvm-svn: 321917
This allows you to dump C++ code that spells bool instead of _Bool, leaves off the elaborated type specifiers when printing struct or class names, and other C-isms.
Fixes the -Wreorder issue and fixes the ast-dump-color.cpp test.
llvm-svn: 321310
This allows you to dump C++ code that spells bool instead of _Bool, leaves off the elaborated type specifiers when printing struct or class names, and other C-isms.
llvm-svn: 321223
This mimics FileCheck's --check-prefixes option.
The default prefix is "expected". That is, "-verify" is equivalent to
"-verify=expected".
The goal is to permit exercising a single test suite source file with different
compiler options producing different sets of diagnostics. While cpp can be
combined with the existing -verify to accomplish the same goal, source is often
easier to maintain when it's not cluttered with preprocessor directives or
duplicate passages of code. For example, this patch also rewrites some existing
clang tests to demonstrate the benefit of this feature.
Patch by Joel E. Denny, thanks!
Differential Revision: https://reviews.llvm.org/D39694
llvm-svn: 320908
The frontend currently groups diagnostics from the command line according to
diagnostic level, but that places all notes last. Fix that by emitting such
diagnostics in the order they were generated.
Patch by Joel E. Denny, thanks!
Differential Revision: https://reviews.llvm.org/D40995
llvm-svn: 320904
The driver-based test is still not identical to the front-end line, remove the
hotness threshold from there and add a new front-end based test with
threshold.
llvm-svn: 319578
1. Require hotness on all remark lines with -verify.
3. Fix the samplePGO file to actually produce hotness on each line.
The second remark has hotness 60 rather 30 which I don't quite understand but
testing this is strictly better than before. It also unblocks the commit of
D40678.
llvm-svn: 319577
A RUN line was referring to the previous RUN line but a new test was added in
between them. Just reorder the lines.
Note this still does not completely fix this the brokenness of the comment as
the driver-based test gained a new hotness-threshold argument in r306948 but
I'll fix that is a separate commit.
llvm-svn: 319576
Lifting from Bob Wilson's notes: The hash value that we compute and
store in PGO profile data to detect out-of-date profiles does not
include enough information. This means that many significant changes to
the source will not cause compiler warnings about the profile being out
of date, and worse, we may continue to use the outdated profile data to
make bad optimization decisions. There is some tension here because
some source changes won't affect PGO and we don't want to invalidate the
profile unnecessarily.
This patch adds a new hashing scheme which is more sensitive to loop
nesting, conditions, and out-of-order control flow. Here are examples
which show snippets which get the same hash under the current scheme,
and different hashes under the new scheme:
Loop Nesting Example
--------------------
// Snippet 1
while (foo()) {
while (bar()) {}
}
// Snippet 2
while (foo()) {}
while (bar()) {}
Condition Example
-----------------
// Snippet 1
if (foo())
bar();
baz();
// Snippet 2
if (foo())
bar();
else
baz();
Out-of-order Control Flow Example
---------------------------------
// Snippet 1
while (foo()) {
if (bar()) {}
baz();
}
// Snippet 2
while (foo()) {
if (bar())
continue;
baz();
}
In each of these cases, it's useful to differentiate between the
snippets because swapping their profiles gives bad optimization hints.
The new hashing scheme considers some logical operators in an effort to
detect more changes in conditions. This isn't a perfect scheme. E.g, it
does not produce the same hash for these equivalent snippets:
// Snippet 1
bool c = !a || b;
if (d && e) {}
// Snippet 2
bool f = d && e;
bool c = !a || b;
if (f) {}
This would require an expensive data flow analysis. Short of that, the
new hashing scheme looks reasonably complete, based on a scan over the
statements we place counters on.
Profiles which use the old version of the PGO hash remain valid and can
be used without issue (there are tests in tree which check this).
rdar://17068282
Differential Revision: https://reviews.llvm.org/D39446
llvm-svn: 318229
This updates -mcount to use the new attribute names (LLVM r318195), and
switches over -finstrument-functions to also use these attributes rather
than inserting instrumentation in the frontend.
It also adds a new flag, -finstrument-functions-after-inlining, which
makes the cygprofile instrumentation get inserted after inlining rather
than before.
Differential Revision: https://reviews.llvm.org/D39331
llvm-svn: 318199
This is a recommit of r312781; in some build configurations
variable names are omitted, so changed the new regression
test accordingly.
llvm-svn: 312794
This adds _Float16 as a source language type, which is a 16-bit floating point
type defined in C11 extension ISO/IEC TS 18661-3.
In follow up patches documentation and more tests will be added.
Differential Revision: https://reviews.llvm.org/D33719
llvm-svn: 312781
This patch adds a flag -fclang-abi-compat that can be used to request that
Clang attempts to be ABI-compatible with some older version of itself.
This is provided on a best-effort basis; right now, this can be used to undo
the ABI change in r310401, reverting Clang to its prior C++ ABI for pass/return
by value of class types affected by that change, and to undo the ABI change in
r262688, reverting Clang to using integer registers rather than SSE registers
for passing <1 x long long> vectors. The intent is that we will maintain this
backwards compatibility path as we make ABI-breaking fixes in future.
The reversion to the old behavior for r310401 is also applied to the PS4 target
since that change is not part of its platform ABI (which is essentially to do
whatever Clang 3.2 did).
llvm-svn: 311823
Discovered due to a goofy git setup, the test system-headerline-directive.c
(and a few others) failed because the token-consumption will consume only the
'\r' in CRLF, making the preprocessor's printed value give the wrong line number
when returning from an include. For example:
(line 1):#include <noline.h>\r\n
The "file exit" code causes the printer to try to print the 'returned to the
main file' line. It looks up what the current line number is. However, since the
current 'token' is the '\n' (since only the \r was consumed), it will give the
line number as '1", not '2'. This results in a few failed tests, but more
importantly, results in error messages being incorrect when compiling a
previously preprocessed file.
Differential Revision: https://reviews.llvm.org/D37079
llvm-svn: 311683
The original patch was an improvement to IR ValueTracking on non-negative
integers. It has been checked in to trunk (D18777, r284022). But was disabled by
default due to performance regressions.
Perf impact has improved. The patch would be enabled by default.
Reviewers: reames, hfinkel
Differential Revision: https://reviews.llvm.org/D34101
Patch by: Olga Chupina <olga.chupina@intel.com>
llvm-svn: 310582
Summary:
Tools like clang that use RemoveFileOnSignal on their output files
weren't actually able to clean up their outputs before this change. Now
the call to llvm::sys::fs::remove succeeds and the temporary file is
deleted. This is a stop-gap to fix clang before implementing the
solution outlined in PR34070.
Reviewers: davide
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D36337
llvm-svn: 310137
Summary:
Un-revert https://reviews.llvm.org/D34868, but with a slight tweak to the
documentation to fix an error -- I had used the wrong syntax for a link.
llvm-svn: 306948
Summary:
Depends on https://reviews.llvm.org/D34867.
Add a Clang frontend option to enable optimization remark hotness
thresholds, which were added to LLVM in https://reviews.llvm.org/D34867.
This prevents diagnostics that do not meet a minimum hotness
threshold from being output. When generating optimization remarks for large
codebases with a ton of cold code paths, this option can be used
to limit the optimization remark output at a reasonable size.
Discussion of this change can be read here:
http://lists.llvm.org/pipermail/llvm-dev/2017-June/114377.html
Reviewers: anemet, davidxl, hfinkel
Reviewed By: anemet
Subscribers: fhahn, cfe-commits
Differential Revision: https://reviews.llvm.org/D34868
llvm-svn: 306945
Summary:
Prior to this change, using `-fdiagnostics-show-hotness` with a sampling
profile specified via `-fprofile-sample-use=` would result in the Clang
frontend emitting a warning: "argument '-fdiagnostics-show-hotness' requires
profile-guided optimization information". Of course, a sampling profile
*is* profile-guided optimization information, so the warning is misleading.
Furthermore, despite the warning, hotness was displayed based on the data in
the sampling profile.
Prevent the warning from being emitted when a sampling profile is used, and
add a test that verifies this.
Reviewers: anemet, davidxl
Reviewed By: davidxl
Subscribers: danielcdh, cfe-commits
Differential Revision: https://reviews.llvm.org/D34082
llvm-svn: 306079
for preprocessing
r300667 added support for editor placeholder to Clang. That commit didn’t take
into account that users who use Clang for preprocessing only (-E) will get the
"editor placeholder in source file" error when preprocessing their source
(PR33394). This commit ensures that Clang doesn't lex editor placeholders when
running a preprocessor only action.
rdar://32718000
Differential Revision: https://reviews.llvm.org/D34256
llvm-svn: 305576
Also comes with a cmake cache for building the runtime bits:
$ cmake <normal cmake flags> \
-DBAREMETAL_ARMV6M_SYSROOT=/path/to/sysroot \
-DBAREMETAL_ARMV7M_SYSROOT=/path/to/sysroot \
-DBAREMETAL_ARMV7EM_SYSROOT=/path/to/sysroot \
-C /path/to/clang/cmake/caches/BaremetalARM.cmake \
/path/to/llvm
https://reviews.llvm.org/D33259
llvm-svn: 303873
This allows #line directives to appear in system headers that have code
that clang would normally warn on. This is compatible with GCC, which is
easy to test by running `gcc -E`.
Fixes PR30752
llvm-svn: 303582
Many of our supported configurations support modules but do not have any
first-class syntax to perform a module import. This leaves us with a problem:
there is no way to represent the expansion of a #include that imports a module
in the -E output for such languages. (We don't want to just leave it as a
#include because that requires the consumer of the preprocessed source to have
the same file system layout and include paths as the creator.)
This patch adds a new pragma:
#pragma clang module import MODULE.NAME.HERE
that imports a module, and changes -E and -frewrite-includes to use it when
rewriting a #include that maps to a module import. We don't make any attempt
to use a native language syntax import if one exists, to get more consistent
output. (If in the future, @import and #include have different semantics in
some way, the pragma will track the #include semantics.)
llvm-svn: 301725
We already prohibited this in most cases (in r130710), but had some bugs in our
enforcement of this rule. Specifically, this prevents the following
combinations:
* -x c -std=clN.M, which would previously effectively act as if -x cl were
used, despite the input being a C source file. (-x cl -std=cNN continues
to be disallowed.)
* -x c++ -std=cuda, which would previously select C++98 + CUDA, despite that
not being a C++ standard. (-x cuda -std=c++NN is still permitted, and
selects CUDA with the given C++ standard as its base language.
-x cuda -std=cuda is still supported with the meaning of CUDA + C++98.)
* -x renderscript -std=c++NN, which would previously form a hybrid "C++ with
RenderScript extensions" language. We could support such a thing, but
shouldn't do so by accident.
llvm-svn: 301497
This commit adds support for a new -iframeworkwithsysroot compiler option which
allows the user to specify a framework path that can be prefixed with the
sysroot. This option is similar to the -iwithsysroot option that exists to
supplement -isystem.
rdar://21316352
Differential Revision: https://reviews.llvm.org/D30183
llvm-svn: 297614
Yevgeny Rouban