| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
via -fmodule-file= to be turned off; in that case, just include the relevant
files textually. This allows module files to be unconditionally passed to all
compile actions via CXXFLAGS, and to be ignored for rules that specify custom
incompatible flags.
llvm-svn: 250577
|
|
|
|
| |
llvm-svn: 250559
|
|
|
|
|
|
| |
requesting module. No functionality change.
llvm-svn: 250554
|
|
|
|
|
|
|
|
|
| |
If you increase the number of diags of a particular type by one more than the
number available you get the nice assert message. If you do it by two more
than available you get the old non-helpful message. Combining the two makes
sense I think.
llvm-svn: 250546
|
|
|
|
|
|
|
| |
Also move the addLibStdCXXIncludePaths helper function from Linux to
Generic_GCC.
llvm-svn: 250536
|
|
|
|
| |
llvm-svn: 250514
|
|
|
|
| |
llvm-svn: 250500
|
|
|
|
| |
llvm-svn: 250498
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r246877 made __builtin_object_size substantially more aggressive with
unknown bases if Type=1 or Type=3, which causes issues when we encounter
code like this:
struct Foo {
int a;
char str[1];
};
const char str[] = "Hello, World!";
struct Foo *f = (struct Foo *)malloc(sizeof(*f) + strlen(str));
strcpy(&f->str, str);
__builtin_object_size(&f->str, 1) would hand back 1, which is
technically correct given the type of Foo, but the type of Foo lies to
us about how many bytes are available in this case.
This patch adds support for this "writing off the end" idiom -- we now
answer conservatively when we're given the address of the very last
member in a struct.
Differential Revision: http://reviews.llvm.org/D12169
llvm-svn: 250488
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, our logic when taking the address of an overloaded function
would not consider enable_if attributes, so long as all of the enable_if
conditions on a given candidate were true. So, two functions with
identical signatures (one with enable_if attributes, the other without),
would be considered equally good overloads. If we were calling the
function instead of taking its address, then the function with enable_if
attributes would be preferred.
This patch makes us prefer the candidate with enable_if regardless of if
we're calling or taking the address of an overloaded function.
Differential Revision: http://reviews.llvm.org/D13795
llvm-svn: 250486
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
match the feature set of the function that they're being called from.
This ensures that we can effectively diagnose some[1] code that would
instead ICE in the backend with a failure to select message.
Example:
__m128d foo(__m128d a, __m128d b) {
return __builtin_ia32_addsubps(b, a);
}
compiled for normal x86_64 via:
clang -target x86_64-linux-gnu -c
would fail to compile in the back end because the normal subtarget
features for x86_64 only include sse2 and the builtin requires sse3.
[1] We're still not erroring on:
__m128i bar(__m128i const *p) { return _mm_lddqu_si128(p); }
where we should fail and error on an always_inline function being
inlined into a function that doesn't support the subtarget features
required.
llvm-svn: 250473
|
|
|
|
|
|
|
|
|
| |
This recommits r250398 with fixes to the tests for bot failures.
Add "-target x86_64-unknown-linux" to the clang invocations that
check for the gold plugin.
llvm-svn: 250455
|
|
|
|
| |
llvm-svn: 250428
|
|
|
|
|
|
|
|
|
|
|
| |
Chromium follows the Android style guide for Java code, and that doesn't make
the distinction between fields and non-fields that the Google Java style guide
makes:
https://source.android.com/source/code-style.html#use-standard-java-annotations
https://google.github.io/styleguide/javaguide.html#s4.8.5-annotations
llvm-svn: 250422
|
|
|
|
| |
llvm-svn: 250418
|
|
|
|
|
|
|
| |
The core C library has already been ported over to aarch64 successfully,
meaning there is no reason to hold this change back.
llvm-svn: 250416
|
|
|
|
|
|
|
|
|
|
|
| |
Rolling this back for now since there are a couple of bot failures on
the new tests I added, and I won't have a chance to look at them in detail
until later this afternoon. I think the new tests need some restrictions on
having the gold plugin available.
This reverts commit r250398.
llvm-svn: 250402
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add clang support for -flto=thin option, which is used to set the
EmitFunctionSummary code gen option on compiles.
Add -flto=full as an alias to the existing -flto.
Add tests to check for proper overriding of -flto variants on the
command line, and convert grep tests to FileCheck.
Reviewers: dexonsmith, joker.eph
Subscribers: davidxl, cfe-commits
Differential Revision: http://reviews.llvm.org/D11908
llvm-svn: 250398
|
|
|
|
| |
llvm-svn: 250388
|
|
|
|
|
|
| |
Patch by Amaury Sechet!
llvm-svn: 250373
|
|
|
|
|
|
| |
defines for the same. And add the flags to correct CPU names.
llvm-svn: 250368
|
|
|
|
| |
llvm-svn: 250363
|
|
|
|
|
|
|
|
| |
X86 feature controls. NFC
This simplifies the constructor initialization list and makes it less likely a feature flag will be forgotten there.
llvm-svn: 250348
|
|
|
|
| |
llvm-svn: 250301
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was a minor problem with a test. Sorry for the noise yesterday.
This patch adds missing pieces to clang, including the PS4 toolchain
definition, added warnings, PS4 defaults, and Driver changes needed for
our compiler.
A patch by Filipe Cabecinhas, Pierre Gousseau and Katya Romanova!
Differential Revision: http://reviews.llvm.org/D13482
llvm-svn: 250293
|
|
|
|
|
|
|
| |
It is breaking llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast
e.g. http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/1362
llvm-svn: 250273
|
|
|
|
|
|
|
|
|
| |
invocations of foo() when compiling foo()->propertyName
Removes extra codegen for base expression of MS property call
Differential Revision: http://reviews.llvm.org/D13375
llvm-svn: 250265
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Resubmitting the patch.
This patch adds missing pieces to clang, including the PS4 toolchain
definition, added warnings, PS4 defaults, and Driver changes needed for
our compiler.
A patch by Filipe Cabecinhas, Pierre Gousseau and Katya Romanova!
Differential Revision: http://reviews.llvm.org/D13482
llvm-svn: 250262
|
|
|
|
| |
llvm-svn: 250257
|
|
|
|
|
|
|
|
|
|
|
| |
definition, added warnings, PS4 defaults, and Driver changes needed for
our compiler.
A patch by Filipe Cabecinhas, Pierre Gousseau and Katya Romanova!
Differential Revision: http://reviews.llvm.org/D13482
llvm-svn: 250252
|
|
|
|
|
|
| |
extensions as continuation of the class interface.
llvm-svn: 250250
|
|
|
|
|
|
|
|
|
|
|
|
| |
methods (PR 21606)
Prevent invalidation of `this' when a method is const; fixing PR 21606.
A patch by Sean Eveson!
Differential Revision: http://reviews.llvm.org/D13099
llvm-svn: 250237
|
|
|
|
| |
llvm-svn: 250202
|
|
|
|
|
|
|
|
| |
This removes the default of 3 hidden in the assembler previously.
Fixes breakage caused by r249655, reported by vsukharev.
llvm-svn: 250173
|
|
|
|
|
|
|
|
| |
This is what most people want anyways. Clang -cc1's main() will override
this but for other tools this is the most sensible default and avoids
some work.
llvm-svn: 250164
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add intrinsics for the
XSAVE instructions (XSAVE/XSAVE64/XRSTOR/XRSTOR64)
XSAVEOPT instructions (XSAVEOPT/XSAVEOPT64)
XSAVEC instructions (XSAVEC/XSAVEC64)
XSAVES instructions (XSAVES/XSAVES64/XRSTORS/XRSTORS64)
Differential Revision: http://reviews.llvm.org/D13014
llvm-svn: 250158
|
|
|
|
|
|
| |
say which module file referenced the missing file.
llvm-svn: 250140
|
|
|
|
|
|
|
|
|
| |
context (but otherwise at the top level) to be disabled, to support use of C++
standard library implementations that (legitimately) mark their <blah.h>
headers as being C++ headers from C libraries that wrap things in 'extern "C"'
a bit too enthusiastically.
llvm-svn: 250137
|
|
|
|
|
|
|
|
|
|
|
| |
We model predefined declarations as not being from AST files, but in most ways
they act as if they come from some implicit prebuilt module file imported
before all others. Therefore, if we see an update to the predefined 'struct
__va_list_tag' declaration (and we've already loaded any modules), it needs a
corresponding update record, even though it didn't technically come from an AST
file.
llvm-svn: 250134
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Add decayedType and hasDecayedType AST matchers
Reviewers: klimek
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D13639
llvm-svn: 250114
|
|
|
|
|
|
| |
We already silently ignore the /RTC, which controls the same functionality.
llvm-svn: 250099
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add support for the `-fdebug-prefix-map=` option as in GCC. The syntax is
`-fdebug-prefix-map=OLD=NEW`. When compiling files from a path beginning with
OLD, change the debug info to indicate the path as start with NEW. This is
particularly helpful if you are preprocessing in one path and compiling in
another (e.g. for a build cluster with distcc).
Note that the linearity of the implementation is not as terrible as it may seem.
This is normally done once per file with an expectation that the map will be
small (1-2) entries, making this roughly linear in the number of input paths.
Addresses PR24619.
llvm-svn: 250094
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bug where one can take the address of a conditionally
enabled function to drop its enable_if guards. For example:
int foo(int a) __attribute__((enable_if(a > 0, "")));
int (*p)(int) = &foo;
int result = p(-1); // compilation succeeds; calls foo(-1)
Overloading logic has been updated to reflect this change, as well.
Functions with enable_if attributes that are always true are still
allowed to have their address taken.
Differential Revision: http://reviews.llvm.org/D13607
llvm-svn: 250090
|
|
|
|
|
|
|
|
|
| |
Fixed a bug where we'd emit multiple diagnostics if there was a problem
taking the address of an overloaded template function.
Differential Revision: http://reviews.llvm.org/D13664
llvm-svn: 250078
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a more principled version of what I did earlier. Path
normalization is generally a good thing, but may break users in strange
environments, e. g. using lots of symlinks. Let the user choose and
default it to on.
This also changes adding a duplicated file into returning an error if
the file contents are different instead of an assertion failure.
Differential Revision: http://reviews.llvm.org/D13658
llvm-svn: 250060
|
|
|
|
| |
llvm-svn: 250043
|
|
|
|
|
|
|
| |
Actually the only special path we have to handle is ./foo, the rest is
tricky to get right so do the same thing as the existing YAML vfs here.
llvm-svn: 250036
|
|
|
|
|
|
|
|
|
| |
This can fail badly if we're overlaying a real file system and there are
symlinks there. Just keep the path as-is for now.
This essentially reverts r249830.
llvm-svn: 250021
|
|
|
|
|
|
|
| |
Automatically insert line feed after pretty printing of all pragma-like attributes + fix printing of pragma-like pragmas on declarations.
Differential Revision: http://reviews.llvm.org/D13546
llvm-svn: 250017
|
|
|
|
|
|
|
|
|
|
| |
key in Obj-C dictionary literals
This fixes: https://llvm.org/PR22647
Patch by Kent Sutherland. Thank you.
llvm-svn: 250010
|