Manman Ren [Tue, 17 May 2016 02:15:12 +0000 (02:15 +0000)]
Modules: set SystemHeader to true if we are building a system module.
If we are processing a #include from a module build, we should treat it
as a system header if we're building a system module. Passing an optional
flag to HeaderSearch::LookupFile.
Before this, the testing case will crash when accessing a freed FileEntry.
Added doxygen comments to avxintrin.h's intrinsics. As of now, only around 50% of the intrinsics in this file are documented here. The patches for the other half will be sent out later.
Updated bmiintrin.h to fix an incorrect section name.
Updated f16cintrin.h to fix incorect parameter names.
The doxygen comments are automatically generated based on Sony's intrinsics document.
I got an OK from Eric Christopher to commit doxygen comments without prior code
review upstream.
Richard Smith [Mon, 16 May 2016 22:53:19 +0000 (22:53 +0000)]
Switch from SmallVector to TinyPtrVector for the list of attributes on a declaration. This removes a memory allocation for the common case where the declaration has only one attribute.
Sean Callanan [Mon, 16 May 2016 20:48:03 +0000 (20:48 +0000)]
Added support to the ASTImporter for C++ constructor initializers.
Also added named casts and propagation of "implicit" to fix the LLDB testsuite.
This is a fixed commit of r269546, which was reverted by r269575.
Steven Wu [Mon, 16 May 2016 18:54:58 +0000 (18:54 +0000)]
Change embed-bitcode linkage type
Embedded bitcode should have private linkage instead of appending or external.
Otherwise, it will cause link failure due to duplicated symbols.
Also add llvm.embedded.module and llvm.cmdline to llvm.compiler.used so they
don't get optimized out.
Nico Weber [Mon, 16 May 2016 18:14:07 +0000 (18:14 +0000)]
[ms] Reintroduce feature guards in intrinsic headers in Microsoft mode
Visual Studio's C++ standard library headers include intrin.h, so the intrinsic
headers get included a lot more often in Microsoft mode than elsewhere. The
AVX512 intrinsics are a lot of code (0.7 MB, causing 30% compile time overhead
for small programs including e.g. <string> and 6% compile time overhead for
larger projects like e.g. v8). Since multiversioning can't be relied on in
Microsoft mode (cl.exe doesn't support it), having faster compiles seems like
the much better tradeoff until we have a better intrinsic story going forward
(which we'll need for e.g. PR19898).
Actually using intrinsics on Windows already requires the right /arch:
settings, so this patch should have no big behavior change.
See also thread "The intrinsics headers (especially avx512) are too big. What
to do about it?" on cfe-dev.
Paul Robinson [Mon, 16 May 2016 17:22:25 +0000 (17:22 +0000)]
[PS4] Change the names of some "environmental" things to what our
licensees actually see in the toolchain we deliver to them. This will
reduce the set of local patches we have to maintain. The triple is
not changing. (The term ORBIS is an internal code name for PS4.)
Yaxun Liu [Mon, 16 May 2016 17:06:34 +0000 (17:06 +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.
Re-commit after fixing build error due to missing override attribute.
[Modules] Use vfs for (recursive) directory iteration
Clang performs directory walk while searching headers inside modules by
using the ::sys::fs instead of ::vfs. This prevents any code that uses
the VFS (e.g, reproducer scripts) to actually find such headers, since
the VFS will never be searched for those.
Change these places to use vfs::recursive_directory_iterator and
vfs::directory_iterator instead.
[mips] Add test for the dynamic linker when using the mips64el-fedora-linux triple.
We should use the musl linker only when there's no environment specified and
the vendor is MTI. The new test verifies this behaviour and is a follow-up to
the r269411 commit that added the vendor field check.
Craig Topper [Sun, 15 May 2016 20:10:03 +0000 (20:10 +0000)]
[AVX512] Move unary negations to the left side of typecasts to specific vector type. The __m128/__m256/__m512 types should be treated more opaquely and not have any operations performed on them.
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.
projects / clang / log