Oleksiy Vyalov [Sat, 14 May 2016 19:07:13 +0000 (19:07 +0000)]
Revert r269546 "Added support to the ASTImporter for C++ constructor initializers." as it breaks TestDataFormatterSynthVal.DataFormatterSynthValueTestCase.test_with_run_command_dwarf test - http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/14699
Daniel Sanders [Sat, 14 May 2016 12:43:08 +0000 (12:43 +0000)]
[mips] Enable IAS by default for 32-bit MIPS targets (O32).
Summary:
The MIPS IAS can now pass 'ninja check-all', recurse, build a bootable linux
kernel, and pass a variety of LNT testing.
Unfortunately we can't enable it by default for 64-bit targets yet since the N32
ABI is still very buggy and this also means we can't enable it for N64 either
because we can't distinguish between N32 and N64 in the relevant code.
Sean Callanan [Sat, 14 May 2016 06:24:14 +0000 (06:24 +0000)]
Update identifiers as needed when loading macros from serialized ASTs.
This is essential for iterating across macros properly, which LLDB does when
loading macros from modules. A naiver version of this patch (without the
conditional) caused assertion failures in the testsuite, but this version should
be safe.
Thanks to Ben Langmuir for the refinement that made this work.
Sean Callanan [Sat, 14 May 2016 06:11:19 +0000 (06:11 +0000)]
Fixed a bug where the ASTImporter didn't propagate builtin IDs at all.
IdentifierInfos are assigned builtin IDs during parsing, but Idents.get() does
not do that work. So the ASTImporter needs to additionally set the builtin ID
for the newly-created IdentifierInfo. This patch does that.
Currently ASTMerge tests only check syntax and the ASTMatchers don't check for
builtin IDs, so this is tricky to test, but LLDB will have a test for this.
Craig Topper [Sat, 14 May 2016 06:03:13 +0000 (06:03 +0000)]
[X86] Change most 'void' pointers in builtin type lists to more correct types. Fix some unaligned load/store intrinsics to use a less aligned type in their pointer casts.
Sean Callanan [Sat, 14 May 2016 05:43:57 +0000 (05:43 +0000)]
Handle injected class names in the ASTImporter.
Every class as parsed by Clang has a forward declaration of itself as a member:
class A {
class A;
...
}
but when the parser generates this it ensures that the RecordTypes for the two
are the same. This makes (among other things) inheritance work. This patch
fixes a bug where the ASTImporter generated two separate RecordTypes when
importing the class and the contained forward declaration, and adds a test case.
Chandler Carruth [Sat, 14 May 2016 05:39:45 +0000 (05:39 +0000)]
Revert "Reapply "[ProfileData] (clang) Use Error in InstrProf and Coverage, NFC""
This reverts commit r269492 as the corresponding LLVM commit was
reverted due to lots of warnings. See the review thread for the original
LLVM commit (r269491) for details.
[VFS] Add level() method to vfs::recursive_directory_iterator
Unlike sys::fs::recursive_directory_iterator,
vfs::recursive_directory_iterator does not implement the level() method,
which tells how deep in the directory tree the current iterator is. This
is needed in the vfs::recursive_directory_iterator so that future
improvements to the crash reproducer will be able to properly access
header for umbrellas when looking into the VFS.
Adrian McCarthy [Fri, 13 May 2016 23:20:11 +0000 (23:20 +0000)]
Get default -fms-compatibility-version from cl.exe's version
-fms-compatibility-version was defaulting to 18 (VS 2013), which is a pain if your environment is pointing to version 19 (VS 2015) libraries.
If cl.exe can be found, this patch uses its version number as the default instead. It re-uses the existing code to find the Visual Studio binaries folder and WinAPI methods to check its version. You can still explicitly specify a compatibility version on the command line. If you don't have cl.exe, this should be a no-op and you'll get the old default of 18.
This affected the tests, which assumed that if you didn't specific a version, that it would default to 18, but this won't be true for all machines. So a couple test cases had to be eliminated and a couple others had to be tweaked to allow for various outputs.
[ModuleMap][CrashReproducer] Collect headers from inner frameworks
(1) Collect headers under inner frameworks (frameworks inside other
other frameworks).
(2) Make sure we also collect the right header files inside them.
More info on (2):
Consider a dummy framework module B, with header Frameworks/B/B.h. Now
consider that another framework A, with header Frameworks/A/A.h, has a
layout with a inner framework Frameworks/A/Frameworks/B/B.h, where the
"B/B.h" part is a symlink for Frameworks/B/B.h. Also assume that
Frameworks/A/A.h includes <B/B.h>.
When parsing header Frameworks/A/A.h, framework module lookup is
performed in search for B, and it happens that
"Frameworks/A/Frameworks/B/B.h" path is registered in the module instead
of real "Frameworks/B/B.h". This occurs because
"Frameworks/A/Frameworks/B/B.h" is scanned first by the FileManager,
when looking for inner framework modules under Frameworks/A/Frameworks.
This makes Frameworks/A/Frameworks/B/B.h the default cached named inside
the FileManager for the B.h file UID.
This leads to modules being built without consistent paths to underlying
header files. This is usually not a problem in regular compilation flow,
but it's an issue when running the crash reproducer. The issue is that
clangs collect "Frameworks/A/Frameworks/B/B.h" but not
"Frameworks/B/B.h" into the VFS, leading to err_mmap_umbrella_clash. So
make sure we also collect the original header.
David Majnemer [Fri, 13 May 2016 20:05:09 +0000 (20:05 +0000)]
[MS ABI] Delegating constructors should not assume they are most derived
A constructor needs to know whether or not it is most derived in order
to determine if it is responsible for virtual bases. Delegating
constructors assumed they were most derived.
Richard Smith [Fri, 13 May 2016 18:48:05 +0000 (18:48 +0000)]
Use marginally more appropriate functions to detect if we should declare an
implicit copy constructor/assignment, and other minor cleanups. No
functionality change intended.
Yaxun Liu [Fri, 13 May 2016 17:16:26 +0000 (17:16 +0000)]
Revert "[OpenCL] Add supported OpenCL extensions to target info."
Revert r269431 due to build failure caused by warning msg:
llvm/tools/clang/lib/Basic/Targets.cpp:2090:9: error: 'setSupportedOpenCLOpts' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
void setSupportedOpenCLOpts() {
Yaxun Liu [Fri, 13 May 2016 15:44:37 +0000 (15:44 +0000)]
[OpenCL] Add supported OpenCL extensions to target info.
Add supported OpenCL extensions to target info. It serves as default values to save the users of the burden setting each supported extensions and optional core features in command line.
Yaron Keren [Fri, 13 May 2016 14:53:19 +0000 (14:53 +0000)]
Prune four superfluous ExternalSemaSource.h includes and one forward declaration in Sema.h
where ExternalSemaSource.h was already included due to ExternalSemaSource:: member uses.
Oleg Ranevskyy [Fri, 13 May 2016 14:45:57 +0000 (14:45 +0000)]
[CodeGen] Clang does not choose aapcs-vfp calling convention for ARM bare metal target with hard float (EABIHF)
Summary:
Clang does not detect `aapcs-vfp` for the EABIHF environment. The reason is that only GNUEABIHF is considered while choosing calling convention, EABIHF is ignored.
This causes clang to use `aapcs` for EABIHF and add the `arm_aapcscc` specifier to functions in generated IR.
The modified `arm-cc.c` test checks that no calling convention specifier is added to functions for EABIHF, which means the default one is used (`CallingConv::ARM_AAPCS_VFP`).
Dmitry Polukhin [Fri, 13 May 2016 09:03:56 +0000 (09:03 +0000)]
[ms][dll] #27212: Generating of implicit special members should take into account MSVC compatibility version
Clang creates implicit move constructor/assign operator in all cases if
there is std=c++11. But MSVC supports such generation starting from
version 1900 only. As result we have some binary incompatibility.
Richard Smith [Fri, 13 May 2016 06:47:56 +0000 (06:47 +0000)]
Add support for derived class special members hiding functions brought in from
a base class via a using-declaration. If a class has a using-declaration
declaring either a constructor or an assignment operator, eagerly declare its
special members in case they need to displace a shadow declaration from a
using-declaration.
Akira Hatanaka [Fri, 13 May 2016 01:21:23 +0000 (01:21 +0000)]
[ObjC][CodeGen] Remove an assert that is no longer correct.
clang asserts when compiling the following code because r231508 made
changes to promote constant temporary arrays and records to globals
with constant initializers:
std::vector<NSString*> strs = {@"a", @"b"};
This commit changes the code to return early if the object returned by
createReferenceTemporary is a global variable with an initializer.
Etienne Bergeron [Thu, 12 May 2016 20:58:56 +0000 (20:58 +0000)]
[AST] Move operations enum to a definition file.
Summary:
This patch moves the enum definitions to a definition (.def) file.
These modifications provide way to list enumerators of a given type.
As an example, this allow parsing of "kinds" in the dynamic matchers.
see: http://reviews.llvm.org/D19871
The dynamic matcher "ofKind" also required this patch to be fixed.
Etienne Bergeron [Thu, 12 May 2016 19:51:18 +0000 (19:51 +0000)]
[Tooling] Fix broken dependency for shared build
Summary:
There virtual destructor can't be found and cause a compilation error
on a shared build.
To repro: [Release + Shared]
```
-DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=ON
```
Which produce this error:
```
tools/clang/unittests/Tooling/CMakeFiles/ToolingTests.dir/ToolingTest.cpp.o: In function `clang::tooling::newFrontendActionFactory_CreatesFrontendActionFactoryFromType_Test::TestBody()':
ToolingTest.cpp:(.text._ZN5clang7tooling66newFrontendActionFactory_CreatesFrontendActionFactoryFromType_Test8TestBodyEv+0x49): undefined reference to `clang::SyntaxOnlyAction::~SyntaxOnlyAction()'
```
[VFS] Reapply #2: Reconstruct the VFS overlay tree for more accurate lookup
Reapply r269100 and r269270, reverted due to
https://llvm.org/bugs/show_bug.cgi?id=27725. Isolate the testcase that
corresponds to the new feature side of this commit and skip it on
windows hosts until we find why it does not work on these platforms.
Original commit message:
The way we currently build the internal VFS overlay representation leads
to inefficient path search and might yield wrong answers when asked for
recursive or regular directory iteration.
Currently, when reading an YAML file, each YAML root entry is placed
inside a new root in the filesystem overlay. In the crash reproducer, a
simple "@import Foundation" currently maps to 43 roots, and when looking
up paths, we traverse a directory tree for each of these different
roots, until we find a match (or don't). This has two consequences:
- It's slow.
- Directory iteration gives incomplete results since it only return
results within one root - since contents of the same directory can be
declared inside different roots, the result isn't accurate.
This is in part fault of the way we currently write out the YAML file
when emitting the crash reproducer - we could generate only one root and
that would make it fast and correct again. However, we should not rely
on how the client writes the YAML, but provide a good internal
representation regardless.
Build a proper virtual directory tree out of the YAML representation,
allowing faster search and proper iteration. Besides the crash
reproducer, this potentially benefits other VFS clients.
Summary:
This option allows the user to control how much of the file name is
emitted by UBSan. Tuning this option allows one to save space in the
resulting binary, which is helpful for restricted execution
environments.
With a positive N, UBSan skips the first N path components.
With a negative N, UBSan only keeps the last N path components.
Diagnostics should note version dependent issues by giving
a hint about current version being compiled for.
This patch changes diagnostics of static storage class specifier
and generic type qualifier to specify OpenCL version as well as
converts other diagnostics to match the style.
David Majnemer [Thu, 12 May 2016 03:51:52 +0000 (03:51 +0000)]
[MS ABI] Don't crash when zero-initializing a vbase which contains a vbase
Bases can be zero-initialized: the storage is zero-initialized before
the base constructor is run.
The MS ABI has a quirk where base VBPtrs are not installed by the
base constructor but by the most derived class. In particular, they are
installed before the base constructor is run.
The derived constructor must be careful to zero-initialize only the bits
of the class which haven't already been populated by virtual base
pointers.
While we correctly avoided this scenario, we didn't handle the case
where the base class has virtual bases which have virtual bases.
[VFS] Reapply r269100: Reconstruct the VFS overlay tree for more accurate lookup
The way we currently build the internal VFS overlay representation leads
to inefficient path search and might yield wrong answers when asked for
recursive or regular directory iteration.
Currently, when reading an YAML file, each YAML root entry is placed
inside a new root in the filesystem overlay. In the crash reproducer, a
simple "@import Foundation" currently maps to 43 roots, and when looking
up paths, we traverse a directory tree for each of these different
roots, until we find a match (or don't). This has two consequences:
- It's slow.
- Directory iteration gives incomplete results since it only return
results within one root - since contents of the same directory can be
declared inside different roots, the result isn't accurate.
This is in part fault of the way we currently write out the YAML file
when emitting the crash reproducer - we could generate only one root and
that would make it fast and correct again. However, we should not rely
on how the client writes the YAML, but provide a good internal
representation regardless.
This patch builds a proper virtual directory tree out of the YAML
representation, allowing faster search and proper iteration. Besides the
crash reproducer, this potentially benefits other VFS clients.
Etienne Bergeron [Thu, 12 May 2016 00:22:28 +0000 (00:22 +0000)]
[tooling] Remove redundant inline keyword
Summary:
The inline keywords are redundant.
Introduce by this commit to try to fix broken build bots:
http://reviews.llvm.org/D20180
Tested on Debug and Release build [linux].
Tested on Release + Shared (-DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=ON) [linux]
Tested on Release [windows]
Richard Smith [Wed, 11 May 2016 20:37:46 +0000 (20:37 +0000)]
Preserve the FoundDecl when performing overload resolution for constructors.
This is in preparation for C++ P0136R1, which switches the model for inheriting
constructors over from synthesizing a constructor to finding base class
constructors (via using shadow decls) when looking for derived class
constructors.
Devin Coughlin [Wed, 11 May 2016 20:28:41 +0000 (20:28 +0000)]
[analyzer] Fix crash in ObjCGenericsChecker
Fix a crash in the generics checker where DynamicTypePropagation tries
to get the superclass of a root class.
This is a spot-fix for a deeper issue where the checker makes assumptions
that may not hold about subtyping between the symbolically-tracked type of
a value and the compile-time types of a cast on that value.
I've added a TODO to address the underlying issue.
Steven Wu [Wed, 11 May 2016 16:26:03 +0000 (16:26 +0000)]
Embed bitcode in object file (clang cc1 part)
Summary:
Teach clang to embed bitcode inside bitcode. When -fembed-bitcode cc1
option is used, clang will embed both the input bitcode and cc1
commandline into the bitcode in special sections before compiling to
the object file. Using -fembed-bitcode-marker will only introduce a
marker in both sections.
Reid Kleckner [Wed, 11 May 2016 16:19:05 +0000 (16:19 +0000)]
Update clang support on recent Haiku
[ Copied from https://llvm.org/bugs/show_bug.cgi?id=26404 ]
clang support on Haiku is lagging a bit, and missing on x86_64.
This patch updates support for x86 and add support for x86_64. It should
apply directly to trunk and it's harmless in the sense that it only
affects Haiku.
This patch fixes a bug where we would assume all value-dependent
enable_if conditions give successful results.
Instead, we consider value-dependent enable_if conditions to always
fail. While this isn't ideal, this is the best we can realistically do
without changing both enable_if's semantics and large parts of Sema
(specifically, all of the parts that don't expect type dependence to
come out of nowhere, and that may interact with overload resolution).
Reid Kleckner [Tue, 10 May 2016 21:00:03 +0000 (21:00 +0000)]
Add -Wcast-calling-convention to warn when casting away calling conventions
Summary:
This only warns on casts of the address of a function defined in the
current TU. In this case, the fix is likely to be local and the warning
useful.
Here are some things we could experiment with in the future:
- Fire on declarations as well as definitions
- Limit the warning to non-void function prototypes
- Limit the warning to mismatches of caller and callee cleanup CCs
This warning is currently off by default while we study its usefulness.
[VFS] Reconstruct the VFS overlay tree for more accurate lookup
The way we currently build the internal VFS overlay representation leads
to inefficient path search and might yield wrong answers when asked for
recursive or regular directory iteration.
Currently, when reading an YAML file, each YAML root entry is placed
inside a new root in the filesystem overlay. In the crash reproducer, a
simple "@import Foundation" currently maps to 43 roots, and when looking
up paths, we traverse a directory tree for each of these different
roots, until we find a match (or don't). This has two consequences:
- It's slow.
- Directory iteration gives incomplete results since it only return
results within one root - since contents of the same directory can be
declared inside different roots, the result isn't accurate.
This is in part fault of the way we currently write out the YAML file
when emitting the crash reproducer - we could generate only one root and
that would make it fast and correct again. However, we should not rely
on how the client writes the YAML, but provide a good internal
representation regardless.
This patch builds a proper virtual directory tree out of the YAML
representation, allowing faster search and proper iteration. Besides the
crash reproducer, this potentially benefits other VFS clients.
Derek Schuff [Tue, 10 May 2016 17:44:46 +0000 (17:44 +0000)]
Do not register incompatible C++ destructors with __cxa_atexit
Summary:
For a static object with a nontrivial destructor, clang generates an
initializer function (__cxx_global_var_init) which registers that
object's destructor using __cxa_atexit. However some ABIs (ARM,
WebAssembly) use destructors that return 'this' instead of having void
return (which does not match the signature of function pointers passed
to __cxa_atexit). This results in undefined behavior when the destructors are
called. All the calling conventions I know of on ARM can tolerate this,
but WebAssembly requires the signatures of indirect calls to match the
called function.
This patch disables that direct registration of destructors for ABIs
that have this-returning destructors.
Alexey Bataev [Tue, 10 May 2016 09:57:36 +0000 (09:57 +0000)]
[OPENMP 4.5] Add codegen support in runtime for '[non]monotonic'
schedule modifiers.
Runtime library expects some additional data in schedule argument for
loop-based directives, that have additional schedule modifiers
'monotonic|nonmonotonic'.
[Sema] Fix an overload resolution bug with enable_if.
Currently, if clang::isBetterOverloadCandidate encounters an enable_if
attribute on either candidate that it's inspecting, it will ignore all
lower priority attributes (e.g. pass_object_size). This is problematic
in cases like:
Artem Belevich [Mon, 9 May 2016 22:09:56 +0000 (22:09 +0000)]
[CUDA] Restrict init of local __shared__ variables to empty constructors only.
Allow only empty constructors for local __shared__ variables in a way
identical to restrictions imposed on dynamic initializers for global
variables on device.
Artem Belevich [Mon, 9 May 2016 19:36:08 +0000 (19:36 +0000)]
[CUDA] Only __shared__ variables can be static local on device side.
According to CUDA programming guide (v7.5):
> E.2.9.4: Within the body of a device or global function, only
> shared variables may be declared with static storage class.
projects / clang / log