| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
This will give more information to the optimizers so that they can reuse stack slots.
llvm-svn: 213379
|
| |
|
|
| |
llvm-svn: 213363
|
| |
|
|
| |
llvm-svn: 213360
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
r211898 introduced a regression where a large struct, which would
normally be passed ByVal, was causing padding to be inserted to
prevent the backend from using some GPRs, in order to follow the
AAPCS. However, the type of the argument was not being set correctly,
so the backend cannot align 8-byte aligned struct types on the stack.
The fix is to not insert the padding arguments when the argument is
being passed ByVal.
llvm-svn: 213359
|
| |
|
|
| |
llvm-svn: 213355
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Revert "Add default feature for CPUs on AArch64 target in Clang"
at r210625. Then, all enabled feature will by passed explicitly by
-target-feature in -cc1 option.
2. Get "-mfpu" deprecated.
3. Implement support of "-march". Usage is:
-march=armv8-a+[no]feature
For instance, "-march=armv8-a+neon+crc+nocrypto". Here "armv8-a" is
necessary, and CPU names are not acceptable. Candidate features are
fp, neon, crc and crypto. Where conflicting feature modifiers are
specified, the right-most feature is used.
4. Implement support of "-mtune". Usage is:
-march=CPU_NAME
For instance, "-march=cortex-a57". This option will ONLY get
micro-architectural feature enabled specifying to target CPU,
like "+zcm" and "+zcz" for cyclone. Any architectural features
WON'T be modified.
5. Change usage of "-mcpu" to "-mcpu=CPU_NAME+[no]feature", which is
an alias to "-march={feature of CPU_NAME}+[no]feature" and
"-mtune=CPU_NAME" together. Where this option is used in conjunction
with -march or -mtune, those options take precedence over the
appropriate part of this option.
llvm-svn: 213353
|
| |
|
|
|
|
|
| |
The parsing code for 'availability' wasn't prepared for string literals
like "a" L"b" showing up. Error if this occurs.
llvm-svn: 213350
|
| |
|
|
| |
llvm-svn: 213349
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* A submodule of module A is imported into module B
* Another submodule of module A that is not imported into B exports a macro
* Some submodule of module B also exports a definition of the macro, and
happens to be the first submodule of B that imports module A.
In this case, we would incorrectly determine that A's macro redefines B's
macro, and so we don't need to re-export B's macro at all.
This happens with the 'assert' macro in an LLVM self-host. =(
llvm-svn: 213348
|
| |
|
|
| |
llvm-svn: 213347
|
| |
|
|
|
|
|
|
|
|
| |
I don't think other implicit members like copy assignment and move
assignment require this treatment, because they should already be
operating on a constructed object.
Fixes PR20351.
llvm-svn: 213346
|
| |
|
|
| |
llvm-svn: 213345
|
| |
|
|
|
|
|
|
|
| |
We were crashing on the relevant test case inputs. Also, refactor this
code a bit so we can report failure and slurp the pragma tokens without
returning a diagnostic id. This is more consistent with the rest of the
parser and sema code.
llvm-svn: 213337
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If, during the initial parse of a template, we perform aggregate initialization
and form an implicit value initialization for an array type, then when we come
to instantiate the template and redo the initialization step, we would try to
match the implicit value initialization up against an array *element*, not to
the complete array.
Remarkably, we've had this bug since ~the dawn of time, but only noticed it
recently.
llvm-svn: 213332
|
| |
|
|
|
|
|
|
|
| |
This reverts commit r213307.
Reverting to have some on-list discussion/confirmation about the ongoing
direction of smart pointer usage in the LLVM project.
llvm-svn: 213325
|
| |
|
|
|
|
|
|
|
| |
(after fixing a bug in MultiplexConsumer I noticed the ownership of the
nested consumers was implemented with raw pointers - so this fixes
that... and follows the source back to its origin pushing unique_ptr
ownership up through there too)
llvm-svn: 213307
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
members (PR20140)
This makes us emit dllexported in-class initialized static data members (which
are treated as definitions in MSVC), even when they're not referenced.
It also makes their special linkage reflected in the GVA linkage instead of
getting massaged in CodeGen.
Differential Revision: http://reviews.llvm.org/D4563
llvm-svn: 213304
|
| |
|
|
|
|
|
|
| |
constants. Comparing int against a constant of the given type like
UINT8_MAX will otherwise force a promotion to unsigned int, which is
typically not expected.
llvm-svn: 213301
|
| |
|
|
| |
llvm-svn: 213299
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Before this patch, you could get lines in the output such as:
Note: including file: ../../dist/include/js/Tc:/path/to/foo.cpp(1,1) : error(clang): static_assert failed...
This patch ensures that the stdout output from showIncludes won't be garbled
in the terminal like this, and it also helps applications that use the output
to generate dependency information if they happen to capture both stdout and
stderr.
Test Plan:
Tested locally, it's hard to write an automated test for this as
the behavior depends on the buffering of the ostreams.
Reviewers: nico
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4559
llvm-svn: 213297
|
| |
|
|
|
|
|
|
|
|
| |
This is used to mark the instructions emitted by Clang to implement
variety of UBSan checks. Generally, we don't want to instrument these
instructions with another sanitizers (like ASan).
Reviewed in http://reviews.llvm.org/D4544
llvm-svn: 213291
|
| |
|
|
| |
llvm-svn: 213289
|
| |
|
|
| |
llvm-svn: 213288
|
| |
|
|
|
|
|
| |
overriden in interfaces and protocols (this is already the case
for properties). rdar://16068470
llvm-svn: 213282
|
| |
|
|
|
|
|
|
| |
This is a follow-up to an IRC conversation with Richard last night; __assume
does not evaluate its argument, and so the argument should not contribute to
whether (__assume(e), constant) can be used where a constant is required.
llvm-svn: 213267
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In MS-compatibility mode, we support the __assume builtin. The __assume builtin
does not evaluate its arguments, and we should issue a warning if __assume is
provided with an argument with side effects (because these effects will be
discarded).
This is similar in spirit to the warnings issued by other compilers (Intel
Diagnostic 2261, MS Compiler Warning C4557).
llvm-svn: 213266
|
| |
|
|
|
|
|
|
| |
synthesizes a temporary std::string from a Twine. Assigning that into a StringRef causes the StringRef to refer to a temporary, and bad things happen.
This fixes a failing test case on Windows.
llvm-svn: 213265
|
| |
|
|
| |
llvm-svn: 213262
|
| |
|
|
| |
llvm-svn: 213261
|
| |
|
|
|
|
|
|
|
|
|
| |
This commit is missing tests and there are a few points that need to be
addressed before a new user-facing option can be added:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140714/110198.html
This reverts commit r213112.
llvm-svn: 213260
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
aaaaaa = aaaaaaaaaaaa ? aaaaaaaaaa ? aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
: aaaaaaaaaaaaaaaaaaaaaa
: aaaaaaaaaaaaaaaaaaaaaaaaaaaa;
After:
aaaaaa = aaaaaaaaaaaa
? aaaaaaaaaa ? aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
: aaaaaaaaaaaaaaaaaaaaaa
: aaaaaaaaaaaaaaaaaaaaaaaaaaaa;
llvm-svn: 213258
|
| |
|
|
| |
llvm-svn: 213257
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Memory barrier __builtin_arm_[dmb, dsb, isb] intrinsics are required to
implement their corresponding ACLE and MSVC intrinsics.
This patch ports ARM dmb, dsb, isb intrinsic to AArch64.
Requires LLVM r213247.
Differential Revision: http://reviews.llvm.org/D4521
llvm-svn: 213250
|
| |
|
|
|
|
| |
There should be no change in semantics at this stage.
llvm-svn: 213249
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
arguments.
Summary:
With this patch (and a corresponding LLVM patch), assembling an empty file with
GCC and Clang -fintegrated-as produce near identical objects. The remaining
differences are:
* GCC/GAS produce objects have a .pdr section
* GCC/GAS produce objects have a .gnu.attributes section
Other differences are insignificant such as precise file offsets and the order
of strings in the string table.
Differential Revision: http://reviews.llvm.org/D4531
llvm-svn: 213241
|
| |
|
|
| |
llvm-svn: 213237
|
| |
|
|
| |
llvm-svn: 213232
|
| |
|
|
|
|
|
|
|
|
|
|
| |
-- a constructor list initialization that unpacked an initializer list into
constructor arguments and
-- a list initialization that created as std::initializer_list and passed it
as the first argument to a constructor
in the AST. Use this flag while instantiating templates to provide the right
semantics for the resulting initialization.
llvm-svn: 213224
|
| |
|
|
|
|
| |
declarations that don't start with 'friend' keyword. Add more unittests.
llvm-svn: 213220
|
| |
|
|
|
|
| |
Only alignment is changed, not required alignment.
llvm-svn: 213217
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to fix debug info emission in the presence of plugins.
When plugins are used the Multiplex(AST)Consumer is employed to dispatch
to both the plugin ASTConsumers and the IRGen ASTConsumer. It wasn't
dispatching a critical call for debug info, resulting in plugin users
having a negative debugging experience.
While I'm here, forward a bunch of other missing calls through the
consumer that seem like they should be there.
To test this, use the example plugin (requires plugins and examples) and
split the test case up so that the plugin testing can be done under that
requirement while the non-plugin testing will execute even in builds
that don't include plugin support or examples.
llvm-svn: 213213
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang supports __assume, at least at the semantic level, when MS extensions are
enabled. Unfortunately, trying to actually compile code using __assume would
result in this error:
error: cannot compile this builtin function yet
__assume is an optimizer hint, and can be ignored at the IR level. Until LLVM
supports assumptions at the IR level, a noop lowering is valid, and that is
what is done here.
llvm-svn: 213206
|
| |
|
|
|
|
|
|
|
| |
constructor (and pass it an implicitly-generated std::initializer_list object),
be sure to mark the resulting construction as list-initialization. This fixes
an assert in template instantiation where we previously thought we'd got direct
non-list initialization without any parentheses.
llvm-svn: 213201
|
| |
|
|
|
|
|
|
| |
however certain sloppy Makefiles pass -z options directly to
the compiler. This patch enables clang to recognize these
options (because -z is not used by clang itself).
llvm-svn: 213198
|
| |
|
|
|
|
| |
scope and syntax information for attributes with custom parsing. It turns out not to matter too much because the FIXME wasn't quite true -- none of these attributes have a C++11 spelling. However, it's still a good change (for instance, we may add an attribute with a type arg in the future for which this code now behaves properly).
llvm-svn: 213191
|
| |
|
|
|
|
| |
for my last patch. // rdar://17631257
llvm-svn: 213185
|
| |
|
|
|
|
|
| |
With this change the memory of buffer in NestedNameSpecifierLocBuilder
is allocated in one place. It also prevents from allocation of tiny blocks.
llvm-svn: 213178
|
| |
|
|
|
|
| |
multilibs from the FSFS toolchain corresponding to the mips32r2/mips64r2 CPUs.
llvm-svn: 213175
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The rewrite facility's footprint is small so it's not worth going to these
lengths to support disabling at configure time, particularly since key compiler
features now depend on it.
Meanwhile the Objective-C rewriters have been moved under the
ENABLE_CLANG_ARCMT umbrella for now as they're comparatively heavy and still
potentially worth excluding from lightweight builds.
Tests are now passing with any combination of feature flags. The flags
historically haven't been tested by LLVM's build servers so caveat emptor.
llvm-svn: 213171
|
| |
|
|
|
|
|
|
|
| |
to be applied to class or protocols. This will direct IRGen
for Objective-C metadata to use the new name in various places
where class and protocol names are needed.
rdar:// 17631257
llvm-svn: 213167
|