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.
http://reviews.llvm.org/D20291
llvm-svn: 269675
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.)
llvm-svn: 269671
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.
Differential Revision: http://reviews.llvm.org/D19484
llvm-svn: 269670
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.
Differential Revision: http://reviews.llvm.org/D20266
rdar://problem/25880368
llvm-svn: 269661
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.
llvm-svn: 269651
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.
Thanks to Doug Gregor for advice on this.
llvm-svn: 269551
-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.
Addresses: https://llvm.org/bugs/show_bug.cgi?id=27215
Differential Revision: http://reviews.llvm.org/D20136
llvm-svn: 269515
(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.
Differential Revision: http://reviews.llvm.org/D20194
rdar://problem/25880368
llvm-svn: 269502
Embedded ARM MachO targets are AAPCS but not full EABI (we don't use
__aeabi_whatever and the functions are allowed to be hard-float).
Turns out there was already a test for this, but its original purpose had
become corrupted over the years.
llvm-svn: 269487
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.
llvm-svn: 269465
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() {
llvm-svn: 269435
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.
Differential Revision: http://reviews.llvm.org/D19484
llvm-svn: 269431
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`).
Reviewers: rengolin, compnerd, t.p.northover
Subscribers: aemerson, rengolin, asl, cfe-commits
Differential Revision: http://reviews.llvm.org/D20219
llvm-svn: 269419
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.
Differential Revision: http://reviews.llvm.org/D19156
Patch by Andrew V. Tischenko
llvm-svn: 269400
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.
llvm-svn: 269398
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.
rdar://problem/25504992
rdar://problem/25955179
Differential Revision: http://reviews.llvm.org/D20045
llvm-svn: 269385
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.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D19666
llvm-svn: 269309
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.
Patch by Vedran Miletic!
Review: http://reviews.llvm.org/D19780
llvm-svn: 269305
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.
llvm-svn: 269271
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.
rdar://problem/26086914
llvm-svn: 269227
This patch implements __unaligned (MS extension) as a proper type qualifier
(before that, it was implemented as an ignored attribute).
It also fixes PR27367 and PR27666.
Differential Revision: http://reviews.llvm.org/D20103
llvm-svn: 269220
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.
Depends on D17390
Reviewers: rsmith
Subscribers: yaron.keren, vsk, cfe-commits
Differential Revision: http://reviews.llvm.org/D17392
llvm-svn: 269202
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).
Differential Revision: http://reviews.llvm.org/D20130
llvm-svn: 269154
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.
Reviewers: thakis, rtrieu
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D17348
llvm-svn: 269116
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.
Subscribers: aemerson, jfb, cfe-commits, dschuff
Differential Revision: http://reviews.llvm.org/D19275
llvm-svn: 269085
directives.
OpenMP 4.5 supports clause 'priority' in task-based directives. Patch
adds initial codegen support for this clause in codegen.
llvm-svn: 269050
If private variables require destructors call at the deletion of the
task, additional flag in task flags must be set. Patch fixes this
problem.
llvm-svn: 269039
Nico Weber