consider the following:
enum E *p;
enum E { e };
The above snippet is not ANSI C because 'enum E' has not bee defined
when we are processing the declaration of 'p'; however, it is a popular
extension to make the above work. This would fail using the Microsoft
enum semantics because the definition of 'E' would implicitly have a
fixed underlying type of 'int' which would trigger diagnostic messages
about a mismatch between the declaration and the definition.
Instead, treat fixed underlying types as not fixed for the purposes of
the diagnostic.
llvm-svn: 249674
Our self hosting buildbots found a few more tests which weren't updated
to reflect that the enum semantics are part of the Microsoft ABI.
llvm-svn: 249670
Enums without an explicit, fixed, underlying type are implicitly given a
fixed 'int' type for ABI compatibility with MSVC. However, we can
enforce the standard-mandated rules on these types as-if we didn't know
this fact if the tag is not part of a definition.
llvm-svn: 249667
These test updates almost exclusively around the change in behavior
around enum: enums without a definition are considered incomplete except
when targeting MSVC ABIs. Since these tests are interested in the
'incomplete-enum' behavior, restrict them to %itanium_abi_triple.
llvm-svn: 249660
No ABI for C++ currently makes it possible to implement the standard
100% perfectly. We wrongly hid some of our compatible behavior behind
-fms-compatibility instead of tying it to the compiler ABI.
llvm-svn: 249656
With this change, most 'g' options are rejected by CompilerInvocation.
They remain only as Driver options. The new way to request debug info
from cc1 is with "-debug-info-kind={line-tables-only|limited|standalone}"
and "-dwarf-version={2|3|4}". In the absence of a command-line option
to specify Dwarf version, the Toolchain decides it, rather than placing
Toolchain-specific logic in CompilerInvocation.
Also fix a bug in the Windows compatibility argument parsing
in which the "rightmost argument wins" principle failed.
Differential Revision: http://reviews.llvm.org/D13221
llvm-svn: 249655
the "" and the suffix; that breaks names such as 'operator""if'. For symmetry,
also remove the space between the 'operator' and the '""'.
llvm-svn: 249641
The backend restores the stack pointer after recovering from an
exception. This is similar to r245879, but it doesn't try to use the
normal cleanup mechanism, so hopefully it won't cause the same breakage.
llvm-svn: 249640
Right now clang_Cursor_getMangling will attempt to mangle any
declaration, even if the declaration isn't mangled (extern C). This
results in a partially mangled name which isn't useful for much. This
patch makes clang_Cursor_getMangling return an empty string if the
declaration isn't mangled.
Patch by Michael Wu <mwu@mozilla.com>.
llvm-svn: 249639
We don't have a good place to put them. Our previous spot was causing us
to optimize loads from the exception object to undef, because it was
after the catchpad instruction that models the write to the catch
object.
llvm-svn: 249616
Currently codegen crashes trying to emit casting to bool &. It happens because bool type is converted to i1 and later then lvalue for reference is converted to i1*. But when codegen tries to load this lvalue it crashes trying to load value from this i1*.
Differential Revision: http://reviews.llvm.org/D13325
llvm-svn: 249534
Right now clang_Cursor_getMangling will attempt to mangle any
declaration, even if the declaration isn't mangled (extern "C"). This
results in a partially mangled name which isn't useful for much. This
patch makes clang_Cursor_getMangling return an empty string if the
declaration isn't mangled.
Patch by Michael Wu <mwu@mozilla.com>.
llvm-svn: 249437
that change turns out to not be reasonable: mutating the AST of a parsed
template during instantiation is not a sound thing to do, does not work across
chained PCH / modules builds, and is in any case a special-case workaround to a
more general problem that should be solved centrally.
llvm-svn: 249342
OpenCL v1.1 s6.2.2: for the boolean value true, every bit in the result vector should be set.
This change treats the i1 value as signed for the purposes of performing the cast to integer,
and therefore sign extend into the result.
Patch by Neil Hickey!
http://reviews.llvm.org/D13349
llvm-svn: 249301
r249137 added support for the new mips-mti-linux toolchain. However,
the new tests of that commit, broke some buildbots because they didn't use
the correct regular expressions to capture the filename of Clang & LLD.
This commit re-applies the changes of r249137 and fixes the tests in
r249137 in order to match the filenames of the Clang and LLD executable.
llvm-svn: 249294
In versions of clang prior to r238238, __declspec was recognized as a keyword in
all modes. It was then changed to only be enabled when Microsoft or Borland
extensions were enabled (and for CUDA, as a temporary measure). There is a
desire to support __declspec in Playstation code, and possibly other
environments. This commit adds a command-line switch to allow explicit
enabling/disabling of the recognition of __declspec as a keyword. Recognition
is enabled by default in Microsoft, Borland, CUDA, and PS4 environments, and
disabled in all other environments.
Patch by Warren Ristow!
llvm-svn: 249279
Diagnose when a pointer to const T is used as the first argument in at atomic
builtin unless that builtin is a load operation. This is already checked for
C11 atomics builtins but not for __atomic ones.
This patch was given the LGTM by rsmith when it was part
of a larger review. (See http://reviews.llvm.org/D10407)
llvm-svn: 249252
The default target is ARM on the ARM self host bots. This is problematic since
the behaviour on x86, x64 is different from ARM. Explicitly pass the target.
This should hopefully fix the ARM bots.
llvm-svn: 249229
The Windows on ARM ABI recommends that FPO be disabled. This is since the
Windows on ARM ABI uses the FP for fast stack walking. By paying the slight
cost of the loss of registers, a much faster backtrace is possible by using the
frame pointer since the pdata need not be consulted. Furthermore, even if pdata
is not available, you can still more easily reconstruct the stack.
llvm-svn: 249227
I randomly came across this difference between AArch64 and other targets:
on the latter, we don't emit nil checks for known non-nil class method
calls thanks to r247350, but we still do for AArch64 stret calls.
They use different code paths, because those are special, as they go
through the regular msgSend, not the msgSend*_stret variants.
llvm-svn: 249205
Ensure that the vptr store in the most-derived constructor is not behind
an invariant group barrier. Previously, the base-most vptr store would
be the one behind no barrier, and that could result in the creator of
the object thinking it had the base-most vtable.
This bug caused clang call pure virtual functions when called from
constructor body.
http://reviews.llvm.org/D13373
llvm-svn: 249197
All global variables that are not enclosed in a declare target region
must be captured in the target region as local variables do. Currently,
there is no support for declare target, so this patch adds support for
capturing all the global variables used in a the target region.
llvm-svn: 249154
This patch implements the outlining for offloading functions for code
annotated with the OpenMP target directive. It uses a temporary naming
of the outlined functions that will have to be updated later on once
target side codegen and registration of offloading libraries is
implemented - the naming needs to be made unique in the produced
library.
llvm-svn: 249148
Reapply r248935.
Usually, when using LTO with a clang installation newer than the
system's one, there's a libLTO.dylib version mismatch and LTO fails. One
solution to this is to make ld point to the right libLTO.dylib by
changing DYLD_LIBRARY_PATH.
However, ld64 supports specifying the complete path to the desired
libLTO.dylib through the -lto_library option. This commit adds support
for the clang driver to use this option whenever it's capable of finding
a libLTO.dylib in clang's installed library directory. This way, we
don't need to rely on DYLD_LIBRARY_PATH nor get caught by version
mismatches.
Differential Revision: http://reviews.llvm.org/D13117
rdar://problem/7363476
llvm-svn: 249143
Currently FastISel doesn't know how to select vector bitcasts.
During instruction selection, fast-isel always falls back to SelectionDAG
every time it encounters a vector bitcast.
As a consequence of this, all the 'packed vector shift by immedate count'
test cases in avx2-builtins.c are optimized by the DAGCombiner.
In particular, the DAGCombiner would always fold trivial stack loads of
constant shift counts into the operands of packed shift builtins.
This behavior would start changing as soon as I reapply revision 249121.
That revision would teach x86 fast-isel how to select bitcasts between vector
types of the same size.
As a consequence of that change, fast-isel would less often fall back to
SelectionDAG. More importantly, DAGCombiner would no longer be able to
simplify the code by folding the stack reload of a constant.
No functional change.
llvm-svn: 249142
Summary:
This new toolchain uses primarily LLVM-based tools, eg. compiler-rt, lld,
libcxx, etc. Because of this, it doesn't require neither an existing GCC
installation nor a GNU environment. Ideally, in a follow-up patch we
would like to add a new --{llvm|clang}-toolchain option (similar to
--gcc-toolchain) in order to allow the use of this toolchain with
independent Clang builds. For the time being, we use the --sysroot
option just to test the correctness of the paths generated by the
driver.
Reviewers: atanasyan, dsanders, rsmith
Subscribers: jfb, tberghammer, danalbert, srhines, dschuff, cfe-commits
Differential Revision: http://reviews.llvm.org/D13340
llvm-svn: 249137
partial specialization can perform conversions on the argument. Be sure we
start again from the original argument when checking each possible template.
llvm-svn: 249114
test that our intrinsics behave the same under -fsigned-char and
-funsigned-char.
This further testing uncovered that AVX-2 has a broken cmpgt for 8-bit
elements, and has for a long time. This is fixed in the same way as
SSE4 handles the case.
The other ISA extensions currently work correctly because they use
specific instruction intrinsics. As soon as they are rewritten in terms
of generic IR, they will need to add these special casts. I've added the
necessary testing to catch this however, so we shouldn't have to chase
it down again.
I considered changing the core typedef to be signed, but that seems like
a bad idea. Notably, it would be an ABI break if anyone is reaching into
the innards of the intrinsic headers and passing __v16qi on an API
boundary. I can't be completely confident that this wouldn't happen due
to a macro expanding in a lambda, etc., so it seems much better to leave
it alone. It also matches GCC's behavior exactly.
A fun side note is that for both GCC and Clang, -funsigned-char really
does change the semantics of __v16qi. To observe this, consider:
% cat x.cc
#include <smmintrin.h>
#include <iostream>
int main() {
__v16qi a = { 1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
__v16qi b = _mm_set1_epi8(-1);
std::cout << (int)(a / b)[0] << ", " << (int)(a / b)[1] << '\n';
}
% clang++ -o x x.cc && ./x
-1, 1
% clang++ -funsigned-char -o x x.cc && ./x
0, 1
However, while this may be surprising, both Clang and GCC agree.
Differential Revision: http://reviews.llvm.org/D13324
llvm-svn: 249097
With -fms-extensions it is possible to have a non-class record that is a
template specialization cause an assertion failure via the call to
Type::getAsCXXRecordDecl. Fixes PR 24246.
llvm-svn: 249090
Objective-C ARC lifetime qualifiers are dropped when canonicalizing
function types. Perform the same adjustment before comparing the
deduced result types of lambdas. Fixes rdar://problem/22344904.
llvm-svn: 249065
Prior to this patch, -Wtautological-overlap-compare would only warn us
if there was a sketchy logical comparison between variables and
IntegerLiterals. This patch makes -Wtautological-overlap-compare aware
of EnumConstantDecls, so it can apply the same logic to them.
llvm-svn: 249053
We support all __sync_val_compare_and_swap_* builtins (only 64-bit on 64-bit
targets) on all cores, and should define the corresponding
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_* macros, just as GCC does. As it turns out,
this is really important because they're needed to prevent a bad ODR violation
with libstdc++'s std::shared_ptr (this is well explained in PR12730).
We were doing this only for P8, but this is necessary on all PPC systems.
llvm-svn: 249009
This reverts commit r248982 as it was breaking the ARM buildbots and the fix didn't work.
This reverts commit r248984, the fix that didn't work.
llvm-svn: 249005
recently when we started using direct conversion to model sign
extension. The __v16qi type we use for SSE v16i8 vectors is defined in
terms of 'char' which may or may not be signed! This causes us to
generate pmovsx and pmovzx depending on the setting of -funsigned-char.
This patch just forms an explicitly signed type and uses that to
formulate the sign extension. While this gets the correct behavior
(which we now verify with the enhanced test) this is just the tip of the
ice berg. Now that I know what to look for, I have found errors of this
sort *throughout* our vector code. Fortunately, this is the only
specific place where I know of users actively having their code
miscompiled by Clang due to this, so I'm keeping the fix for those users
minimal and targeted.
I'll be sending a proper email for discussion of how to fix these
systematically, what the implications are, and just how widely broken
this is... From what I can tell, we have never shipped a correct set of
builtin headers for x86 when users rely on -funsigned-char. Oops.
llvm-svn: 248980
Unqualified templated constructors cannot be friended and our lack of a
diagnostic led to violated invariants. Instead, raise a diagnostic when
processing the friend declaration.
This fixes PR20251.
llvm-svn: 248953
Summary: __nvvm_atom_cas_* returns the old value instead of whether the swap succeeds.
Reviewers: eliben, tra
Subscribers: jholewinski, llvm-commits
Differential Revision: http://reviews.llvm.org/D13306
llvm-svn: 248951
When an Objective-C method implements a protocol requirement, do not
inherit any availability information from the protocol
requirement. Rather, check that the implementation is not less
available than the protocol requirement, as we do when overriding a
method that has availability. Fixes rdar://problem/22734745.
llvm-svn: 248949
Usually, when using LTO with a clang installation newer than the
system's one, there's a libLTO.dylib version mismatch and LTO fails. One
solution to this is to make ld point to the right libLTO.dylib by
changing DYLD_LIBRARY_PATH.
However, ld64 supports specifying the complete path to the desired
libLTO.dylib through the -lto_library option. This commit adds support
for the clang driver to use this option whenever it's capable of finding
a libLTO.dylib in clang's installed library directory. This way, we
don't need to rely on DYLD_LIBRARY_PATH nor get caught by version
mismatches.
Differential Revision: http://reviews.llvm.org/D13117
rdar://problem/7363476
llvm-svn: 248932
We get into this bad state when someone defines a new member function
for a class but forgets to add the declaration to the class body.
Calling the new member function from a member function template of the
class will crash during instantiation.
llvm-svn: 248925
- Remove virtual SC_OpenCLWorkGroupLocal storage type specifier
as it conflicts with static local variables now and prevents
diagnosing static local address space variables correctly.
- Allow static local and global variables (OpenCL2.0 s6.8 and s6.5.1).
- Improve diagnostics of allowed ASes for variables in different scopes:
(i) Global or static local variables have to be in global
or constant ASes (OpenCL1.2 s6.5, OpenCL2.0 s6.5.1);
(ii) Non-kernel function variables can't be declared in local
or constant ASes (OpenCL1.1 s6.5.2 and s6.5.3).
http://reviews.llvm.org/D13105
llvm-svn: 248906
Applied restrictions from OpenCL v2.0 s6.13.11.8
that mainly disallow operations on atomic types (except for taking their address - &).
The patch is taken from SPIR2.0 provisional branch, contributed by Guy Benyei!
llvm-svn: 248896
This is the clang commit associated with llvm r248887.
This commit changes the interface of the vld[1234], vld[234]lane, and vst[1234],
vst[234]lane ARM neon intrinsics and associates an address space with the
pointer that these intrinsics take. This changes, e.g.,
<2 x i32> @llvm.arm.neon.vld1.v2i32(i8*, i32)
to
<2 x i32> @llvm.arm.neon.vld1.v2i32.p0i8(i8*, i32)
This change ensures that address spaces are fully taken into account in the ARM
target during lowering of interleaved loads and stores.
Differential Revision: http://reviews.llvm.org/D13127
llvm-svn: 248888
specification) to an error. No compiler other than Clang seems to allow this,
and it doesn't seem like a useful thing to accept as an extension in general.
The current behavior was added for PR5957, where the problem was specifically
related to mismatches of the exception specification on the implicitly-declared
global operator new and delete. To retain that workaround, we downgrade the
error to an ExtWarn when the declaration is of a replaceable global allocation
function.
Now that this is an error, stop trying (and failing) to recover from a missing
computed noexcept specification. That recovery didn't work, and led to crashes
in code like the added testcase.
llvm-svn: 248867
This patch corresponds to review:
http://reviews.llvm.org/D13190
Implemented the following interfaces to conform to ELF V2 ABI version 1.1.
vector signed __int128 vec_adde (vector signed __int128, vector signed __int128, vector signed __int128);
vector unsigned __int128 vec_adde (vector unsigned __int128, vector unsigned __int128, vector unsigned __int128);
vector signed __int128 vec_addec (vector signed __int128, vector signed __int128, vector signed __int128);
vector unsigned __int128 vec_addec (vector unsigned __int128, vector unsigned __int128, vector unsigned __int128);
vector signed int vec_addc(vector signed int __a, vector signed int __b);
vector bool char vec_cmpge (vector signed char __a, vector signed char __b);
vector bool char vec_cmpge (vector unsigned char __a, vector unsigned char __b);
vector bool short vec_cmpge (vector signed short __a, vector signed short __b);
vector bool short vec_cmpge (vector unsigned short __a, vector unsigned short __b);
vector bool int vec_cmpge (vector signed int __a, vector signed int __b);
vector bool int vec_cmpge (vector unsigned int __a, vector unsigned int __b);
vector bool char vec_cmple (vector signed char __a, vector signed char __b);
vector bool char vec_cmple (vector unsigned char __a, vector unsigned char __b);
vector bool short vec_cmple (vector signed short __a, vector signed short __b);
vector bool short vec_cmple (vector unsigned short __a, vector unsigned short __b);
vector bool int vec_cmple (vector signed int __a, vector signed int __b);
vector bool int vec_cmple (vector unsigned int __a, vector unsigned int __b);
vector double vec_double (vector signed long long __a);
vector double vec_double (vector unsigned long long __a);
vector bool char vec_eqv(vector bool char __a, vector bool char __b);
vector bool short vec_eqv(vector bool short __a, vector bool short __b);
vector bool int vec_eqv(vector bool int __a, vector bool int __b);
vector bool long long vec_eqv(vector bool long long __a, vector bool long long __b);
vector signed short vec_madd(vector signed short __a, vector signed short __b, vector signed short __c);
vector signed short vec_madd(vector signed short __a, vector unsigned short __b, vector unsigned short __c);
vector signed short vec_madd(vector unsigned short __a, vector signed short __b, vector signed short __c);
vector unsigned short vec_madd(vector unsigned short __a, vector unsigned short __b, vector unsigned short __c);
vector bool long long vec_mergeh(vector bool long long __a, vector bool long long __b);
vector bool long long vec_mergel(vector bool long long __a, vector bool long long __b);
vector bool char vec_nand(vector bool char __a, vector bool char __b);
vector bool short vec_nand(vector bool short __a, vector bool short __b);
vector bool int vec_nand(vector bool int __a, vector bool int __b);
vector bool long long vec_nand(vector bool long long __a, vector bool long long __b);
vector bool char vec_orc(vector bool char __a, vector bool char __b);
vector bool short vec_orc(vector bool short __a, vector bool short __b);
vector bool int vec_orc(vector bool int __a, vector bool int __b);
vector bool long long vec_orc(vector bool long long __a, vector bool long long __b);
vector signed long long vec_sub(vector signed long long __a, vector signed long long __b);
vector signed long long vec_sub(vector bool long long __a, vector signed long long __b);
vector signed long long vec_sub(vector signed long long __a, vector bool long long __b);
vector unsigned long long vec_sub(vector unsigned long long __a, vector unsigned long long __b);
vector unsigned long long vec_sub(vector bool long long __a, vector unsigned long long __b);
vector unsigned long long vec_sub(vector unsigned long long __V2 ABI V1.1
http://ror float vec_sub(vector float __a, vector float __b);
unsigned char vec_extract(vector bool char __a, int __b);
signed short vec_extract(vector signed short __a, int __b);
unsigned short vec_extract(vector bool short __a, int __b);
signed int vec_extract(vector signed int __a, int __b);
unsigned int vec_extract(vector bool int __a, int __b);
signed long long vec_extract(vector signed long long __a, int __b);
unsigned long long vec_extract(vector unsigned long long __a, int __b);
unsigned long long vec_extract(vector bool long long __a, int __b);
double vec_extract(vector double __a, int __b);
vector bool char vec_insert(unsigned char __a, vector bool char __b, int __c);
vector signed short vec_insert(signed short __a, vector signed short __b, int __c);
vector bool short vec_insert(unsigned short __a, vector bool short __b, int __c);
vector signed int vec_insert(signed int __a, vector signed int __b, int __c);
vector bool int vec_insert(unsigned int __a, vector bool int __b, int __c);
vector signed long long vec_insert(signed long long __a, vector signed long long __b, int __c);
vector unsigned long long vec_insert(unsigned long long __a, vector unsigned long long __b, int __c);
vector bool long long vec_insert(unsigned long long __a, vector bool long long __b, int __c);
vector double vec_insert(double __a, vector double __b, int __c);
vector signed long long vec_splats(signed long long __a);
vector unsigned long long vec_splats(unsigned long long __a);
vector signed __int128 vec_splats(signed __int128 __a);
vector unsigned __int128 vec_splats(unsigned __int128 __a);
vector double vec_splats(double __a);
int vec_all_eq(vector double __a, vector double __b);
int vec_all_ge(vector double __a, vector double __b);
int vec_all_gt(vector double __a, vector double __b);
int vec_all_le(vector double __a, vector double __b);
int vec_all_lt(vector double __a, vector double __b);
int vec_all_nan(vector double __a);
int vec_all_ne(vector double __a, vector double __b);
int vec_all_nge(vector double __a, vector double __b);
int vec_all_ngt(vector double __a, vector double __b);
int vec_any_eq(vector double __a, vector double __b);
int vec_any_ge(vector double __a, vector double __b);
int vec_any_gt(vector double __a, vector double __b);
int vec_any_le(vector double __a, vector double __b);
int vec_any_lt(vector double __a, vector double __b);
int vec_any_ne(vector double __a, vector double __b);
vector unsigned char vec_sbox_be (vector unsigned char);
vector unsigned char vec_cipher_be (vector unsigned char, vector unsigned char);
vector unsigned char vec_cipherlast_be (vector unsigned char, vector unsigned char);
vector unsigned char vec_ncipher_be (vector unsigned char, vector unsigned char);
vector unsigned char vec_ncipherlast_be (vector unsigned char, vector unsigned char);
vector unsigned int vec_shasigma_be (vector unsigned int, const int, const int);
vector unsigned long long vec_shasigma_be (vector unsigned long long, const int, const int);
vector unsigned short vec_pmsum_be (vector unsigned char, vector unsigned char);
vector unsigned int vec_pmsum_be (vector unsigned short, vector unsigned short);
vector unsigned long long vec_pmsum_be (vector unsigned int, vector unsigned int);
vector unsigned __int128 vec_pmsum_be (vector unsigned long long, vector unsigned long long);
vector unsigned char vec_gb (vector unsigned char);
vector unsigned long long vec_bperm (vector unsigned __int128 __a, vector unsigned char __b);
Removed the folowing interfaces either because their signatures have changed
in version 1.1 of the ABI or because they were implemented for ELF V2 ABI but
have actually been deprecated in version 1.1.
vector signed char vec_eqv(vector bool char __a, vector signed char __b);
vector signed char vec_eqv(vector signed char __a, vector bool char __b);
vector unsigned char vec_eqv(vector bool char __a, vector unsigned char __b);
vector unsigned char vec_eqv(vector unsigned char __a, vector bool char __b);
vector signed short vec_eqv(vector bool short __a, vector signed short __b);
vector signed short vec_eqv(vector signed short __a, vector bool short __b);
vector unsigned short vec_eqv(vector bool short __a, vector unsigned short __b);
vector unsigned short vec_eqv(vector unsigned short __a, vector bool short __b);
vector signed int vec_eqv(vector bool int __a, vector signed int __b);
vector signed int vec_eqv(vector signed int __a, vector bool int __b);
vector unsigned int vec_eqv(vector bool int __a, vector unsigned int __b);
vector unsigned int vec_eqv(vector unsigned int __a, vector bool int __b);
vector signed long long vec_eqv(vector bool long long __a, vector signed long long __b);
vector signed long long vec_eqv(vector signed long long __a, vector bool long long __b);
vector unsigned long long vec_eqv(vector bool long long __a, vector unsigned long long __b);
vector unsigned long long vec_eqv(vector unsigned long long __a, vector bool long long __b);
vector float vec_eqv(vector bool int __a, vector float __b);
vector float vec_eqv(vector float __a, vector bool int __b);
vector double vec_eqv(vector bool long long __a, vector double __b);
vector double vec_eqv(vector double __a, vector bool long long __b);
vector unsigned short vec_nand(vector bool short __a, vector unsigned short __b);
llvm-svn: 248813
Description.
If the simd clause is specified, the ordered regions encountered by any thread will use only a single SIMD lane to execute the ordered regions in the order of the loop iterations.
Restrictions.
An ordered construct with the simd clause is the only OpenMP construct that can appear in the simd region.
An ordered directive with ‘simd’ clause is generated as an outlined function and corresponding function call to prevent this part of code from vectorization later in backend.
llvm-svn: 248772
Currently it's 64-bit which will lead to mismatch between host and
device code if we compile for i386.
Differential Revision: http://reviews.llvm.org/D13181
llvm-svn: 248753
Parsing and sema analysis for 'simd' clause in 'ordered' directive.
Description
If the simd clause is specified, the ordered regions encountered by any thread will use only a single SIMD lane to execute the ordered
regions in the order of the loop iterations.
Restrictions
An ordered construct with the simd clause is the only OpenMP construct that can appear in the simd region
llvm-svn: 248696
ARM EABI adds target attributes to the object file. Amongst the attributes that
are emitted is the VFP argument passing (Hard vs Soft). The linker is
responsible for checking these attributes and erroring on mismatches. This
causes problems for the compiler-rt builtins when targeting both hard and
soft. Because both of these options name the builtins compiler-rt component
the same (libclang_rt.builtins-arm.a or libclang_rt.builtins-arm-android). GCC
is able to get away with this as it does one target per toolchain. This
changes the naming convention for the ARM compiler-rt builtins to differentiate
between HF and Soft. Although this means that compiler-rt may be duplicated, it
enables supporting both variants from a single toolchain. A similar approach is
taken by the Darwin toolchain, naming the library to differentiate between the
calling conventions.
llvm-svn: 248649
Summary:
The store being checked for in arc-cxx11-init-list.mm is a store to an
unescaped alloca. After an uncoming change to ScalarEvolution, LLVM is
able to elide the store, so adjust the test accordingly.
Reviewers: compnerd
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D13183
llvm-svn: 248632
This patch fixes the order in which we evaluate the different ways that
a function call could be disallowed. Now, if you call a non-overloaded
function with an incomplete type and failing enable_if, we'll prioritize
reporting the more obvious error (use of incomplete type) over reporting
the failing enable_if.
Thanks to Ettore Speziale for the patch!
llvm-svn: 248595
OpenMP 4.1 extends format of '#pragma omp ordered'. It adds 3 additional clauses: 'threads', 'simd' and 'depend'.
If no clause is specified, the ordered construct behaves as if the threads clause had been specified. If the threads clause is specified, the threads in the team executing the loop region execute ordered regions sequentially in the order of the loop iterations.
The loop region to which an ordered region without any clause or with a threads clause binds must have an ordered clause without the parameter specified on the corresponding loop directive.
llvm-svn: 248569
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/D11279
llvm-svn: 248546
Currently, the availability of DSP instructions (ACLE 6.4.7) is handled in
a hand-rolled tricky condition block in lib/Basic/Targets.cpp, with a FIXME:
attached.
http://reviews.llvm.org/D12937 moved the handling of the DSP feature over to
ARMTargetParser.def in LLVM, to be in line with other architecture extensions.
This is the corresponding patch to clang, to clear the FIXME: and update
the tests.
Differential Revision: http://reviews.llvm.org/D12938
llvm-svn: 248521
Change the analyzer's modeling of memcpy to be more precise when copying into fixed-size
array fields. With this change, instead of invalidating the entire containing region the
analyzer now invalidates only offsets for the array itself when it can show that the
memcpy stays within the bounds of the array.
This addresses false positive memory leak warnings of the kind reported by
krzysztof in https://llvm.org/bugs/show_bug.cgi?id=22954
(This is the second attempt, now with assertion failures resolved.)
A patch by Pierre Gousseau!
Differential Revision: http://reviews.llvm.org/D12571
llvm-svn: 248516
Summary:
Strictly speaking, the MIPS*R2 ISA's should not permit -mnan=2008 since this
feature was added in MIPS*R3. However, other toolchains permit this and we
should do the same.
Reviewers: atanasyan
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D13057
llvm-svn: 248481
Trace the ranges through the macro backtrace better. This allows better
range highlighting through all levels of the macro bracktrace. Also some
improvements to backtrace printer for omitting different backtraces.
Patch by Zhengkai Wu.
Differential Revision: http://reviews.llvm.org/D12379
llvm-svn: 248454
This patch ignores malloc-overflow bug in two cases:
Case1:
x = a/b; where n < b
malloc (x*n); Then x*n will not overflow.
Case2:
x = a; // when 'a' is a known value.
malloc (x*n);
Also replaced isa with dyn_cast.
Reject multiplication by zero cases in MallocOverflowSecurityChecker
Currently MallocOverflowSecurityChecker does not catch cases like:
malloc(n * 0 * sizeof(int));
This patch rejects such cases.
Two test cases added. malloc-overflow2.c has an example inspired from a code
in linux kernel where the current checker flags a warning while it should not.
A patch by Aditya Kumar!
Differential Revision: http://reviews.llvm.org/D9924
llvm-svn: 248446
silently ignore them on arguments when they're provided indirectly
(.e.g behind a template argument or typedef).
This is mostly just good language design --- specifying that a
generic argument is __weak doesn't actually do anything --- but
it also prevents assertions when trying to apply a different
ownership qualifier.
rdar://21612439
llvm-svn: 248436
someone thought all the bits would be value bits in this case.
Also fix the wording of the warning -- it claimed that the width of 'bool' is
8, which is not correct; the width is 1 bit, whereas the size is 8 bits in our
implementation.
llvm-svn: 248435
Added new option --cuda-path=<path> which allows
overriding default search paths.
If it's not specified we look for CUDA installation in
/usr/include/cuda and /usr/include/cuda-7.0.
Differential Revision: http://reviews.llvm.org/D12989
llvm-svn: 248433
Various improvements to the localization checker:
* Adjusted copy to be consistent with diagnostic text in other Apple
API checkers.
* Added in ~150 UIKit / AppKit methods that require localized strings in
UnlocalizedStringsChecker.
* UnlocalizedStringChecker now checks for UI methods up the class hierarchy and
UI methods that conform for a certain Objective-C protocol.
* Added in alpha version of PluralMisuseChecker and some regression tests. False
positives are still not ideal.
(This is the second attempt, with the memory issues on Linux resolved.)
A patch by Kulpreet Chilana!
Differential Revision: http://reviews.llvm.org/D12417
llvm-svn: 248432
This doesn't quite get alias template equivalence right yet, but handles the
egregious cases where we would silently give the wrong answers.
llvm-svn: 248431
Added new option --cuda-path=<path> which allows
overriding default search paths.
If it's not specified we look for CUDA installation in
/usr/include/cuda and /usr/include/cuda-7.0.
Differential Revision: http://reviews.llvm.org/D12989
llvm-svn: 248408
Adjust __global__ functions with DiscardableODR linkage to use
StrongODR linkage instead, so they are visible externally.
Differential Revision: http://reviews.llvm.org/D13067
llvm-svn: 248400
Our string literal parser copied any source-file new-line characters
into the execution string-literal. This is incorrect if the source-file
new-line character was a \r\n sequence because new-line characters are
merely \n.
llvm-svn: 248392
We took both source locations from the end of the initializer list what
the code below doesn't expect. This can lead to a crash when rendering
the diagnostic (PR24816). Assert that we have more than one element in
a scalar initializer with too many elements.
llvm-svn: 248391
This translates to -load name.so in the cc1 command. We can't name the driver
option -load, as that means "link against oad", so instead we follow GCC's lead
and name the option -fplugin.
llvm-svn: 248378
An assertion hit has been fixed for cmdlines like
$ clang --target=arm-linux-gnueabi -mcpu=generic hello.c
Related to: http://reviews.llvm.org/rL245445
Reviewers: rengolin
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D13013
llvm-svn: 248370
Various improvements to the localization checker:
* Adjusted copy to be consistent with diagnostic text in other Apple
API checkers.
* Added in ~150 UIKit / AppKit methods that require localized strings in
UnlocalizedStringsChecker.
* UnlocalizedStringChecker now checks for UI methods up the class hierarchy and
UI methods that conform for a certain Objective-C protocol.
* Added in alpha version of PluralMisuseChecker and some regression tests. False
positives are still not ideal.
A patch by Kulpreet Chilana!
Differential Revision: http://reviews.llvm.org/D12417
llvm-svn: 248350
when building a module. Clang already records the module signature when
building a skeleton CU to reference a clang module.
Matching the id in the skeleton with the one in the module allows a DWARF
consumer to verify that they found the correct version of the module
without them needing to know about the clang module format.
llvm-svn: 248345
Currently realloc(ptr, 0) is treated as free() which seems to be not correct. C
standard (N1570) establishes equivalent behavior for malloc(0) and realloc(ptr,
0): "7.22.3 Memory management functions calloc, malloc, realloc: If the size of
the space requested is zero, the behavior is implementation-defined: either a
null pointer is returned, or the behavior is as if the size were some nonzero
value, except that the returned pointer shall not be used to access an object."
The patch equalizes the processing of malloc(0) and realloc(ptr,0). The patch
also enables unix.Malloc checker to detect references to zero-allocated memory
returned by realloc(ptr,0) ("Use of zero-allocated memory" warning).
A patch by Антон Ярцев!
Differential Revision: http://reviews.llvm.org/D9040
llvm-svn: 248336
This fixes PR16833, in which the analyzer was using large amounts of memory
for switch statements with large case ranges.
rdar://problem/14685772
A patch by Aleksei Sidorin!
Differential Revision: http://reviews.llvm.org/D5102
llvm-svn: 248318
Summary:
`TypeTraitExpr`s are not supported by the ExprEngine today. Analyzer
creates a sink, and aborts the block. Therefore, certain bugs that
involve type traits intrinsics cannot be detected (see PR24710).
This patch creates boolean `SVal`s for `TypeTraitExpr`s, which are
evaluated by the compiler.
Test within the patch is a summary of PR24710.
Reviewers: zaks.anna, dcoughlin, krememek
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D12482
llvm-svn: 248314
* adds -aux-triple option to specify target triple
* propagates aux target info to AST context and Preprocessor
* pulls in target specific preprocessor macros.
* pulls in target-specific builtins from aux target.
* sets appropriate host or device attribute on builtins.
Differential Revision: http://reviews.llvm.org/D12917
llvm-svn: 248299
* Only the last of the --cuda-host-only/--cuda-device-only options has effect.
* CudaHostAction always wraps host-side compilation now.
* Fixed printing of empty action lists.
Differential Revision: http://reviews.llvm.org/D12892
llvm-svn: 248297
The changes are part of attribute-based CUDA function overloading (D12453)
and as such are only enabled when it's in effect (-fcuda-target-overloads).
Differential Revision: http://reviews.llvm.org/D12122
llvm-svn: 248296
The patch makes it possible to parse CUDA files that contain host/device
functions with identical signatures, but different attributes without
having to physically split source into host-only and device-only parts.
This change is needed in order to parse CUDA header files that have
a lot of name clashes with standard include files.
Gory details are in design doc here: https://goo.gl/EXnymm
Feel free to leave comments there or in this review thread.
This feature is controlled with CC1 option -fcuda-target-overloads
and is disabled by default.
Differential Revision: http://reviews.llvm.org/D12453
llvm-svn: 248295
This makes sure that we emit kernels that were instantiated from the
host code and which would never be explicitly referenced by anything
else on device side.
Differential Revision: http://reviews.llvm.org/D11666
llvm-svn: 248293
Before, clang's internal assembler would reject the inline asm in clang's
Intrin.h. To make sure this doesn't happen for other Intrin.h functions using
__asm__ blocks, add 32-bit and 64-bit codegen tests for Intrin.h.
Sadly, these tests discovered that __readcr3 and __writecr3 have bad
implementations in 64-bit builds. This will have to be fixed in a follow-up.
llvm-svn: 248234
This commit fixes an assert that is triggered when optnone is being
added to an IR function that is already marked with minsize and optsize.
rdar://problem/22723716
Differential Revision: http://reviews.llvm.org/D13004
llvm-svn: 248191
Several inputs may not refer to one output constraint in inline assembler
insertions, clang was failing on assertion on such test case.
llvm-svn: 248158
Currently, the availability of DSP instructions (ACLE 6.4.7) is handled in
a hand-rolled tricky condition block in lib/Basic/Targets.cpp, with a FIXME:
attached.
http://reviews.llvm.org/D12937 moved the handling of +t2dsp over to
ARMTargetParser.def in LLVM, to be in line with other architecture extensions.
This is the corresponding patch to clang, to clear the FIXME: and update
the tests.
Differential Revision: http://reviews.llvm.org/D12938
llvm-svn: 248154
128-bit vector integer sign extensions correctly lower to the pmovsx instructions even for debug builds.
This patch removes the builtins and reimplements the _mm_cvtepi*_epi* intrinsics __using builtin_shufflevector (to extract the bottom most subvector) and __builtin_convertvector (to actually perform the sign extension).
Differential Revision: http://reviews.llvm.org/D12835
llvm-svn: 248092
If an import directive was put into wrong context, the error message was obscure,
complaining on misbalanced braces. To get more descriptive messages, annotation
tokens related to modules are processed where they must not be seen.
Differential Revision: http://reviews.llvm.org/D11844
llvm-svn: 248085
Binary literals predate C++14, but they are listed as a C++14 extension since
this was the first time they were standardized in the language. Move the
warning into a subgroup so it can be selectively disabled when checking for
other C++14 features.
llvm-svn: 248064
Summary:
Name `Out` refers to the parameter. It is moved into the member `Out`
in ctor-init. Dereferencing null pointer will crash clang, if user
passes '-analyzer-viz-egraph-ubigraph' argument.
Reviewers: zaks.anna, krememek
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D12119
llvm-svn: 248050
LLVM r217812 made it so that clang-cl implicitly creates bigobj files when
needed, independent of this flag. It looks like cl has this flag to produce obj
flags compatible with MSVS 2003's linker by default, something we don't care
about. Since clang-cl always has /bigobj behavior, don't warn that the flag is
unused, just ignore it silently.
llvm-svn: 248034
The problem this time was the /clang matching the InstalledDir line.
Now we just use regular expressions which are more flexible, if a bit less
readable, than CHECK+CHECK-SAME.
llvm-svn: 248031
CHECK-LABEL assumes that there is only one occurrence of the match.
The output looks like:
clang version 3.8.0 (trunk 247999)
....
/path/to/build/dir/bin/clang-3.8 ....
If the path contains lld, the second CHECK-LABEL matches it and we fail since
there is no -cc1as between clang and lld.
llvm-svn: 248029
Summary:
This change adds support for `__builtin_ms_va_list`, a GCC extension for
variadic `ms_abi` functions. The existing `__builtin_va_list` support is
inadequate for this because `va_list` is defined differently in the Win64
ABI vs. the System V/AMD64 ABI.
Depends on D1622.
Reviewers: rsmith, rnk, rjmccall
CC: cfe-commits
Differential Revision: http://reviews.llvm.org/D1623
llvm-svn: 247941
Mingw generally wraps an old copy of msvcrt.dll which has these
personalities, so things should work out, or so I hear. I haven't tested
it.
llvm-svn: 247902
convert i64 to FP and vice versa
reduceps & reducepd
rangeps & rangepd
all in their 512bit versions
Differential Revision: http://reviews.llvm.org/D11716
llvm-svn: 247881
The analyzer trims unnecessary nodes from the exploded graph before reporting
path diagnostics. However, in some cases it can trim all nodes (including the
error node), leading to an assertion failure (see
https://llvm.org/bugs/show_bug.cgi?id=24184).
This commit addresses the issue by adding two new APIs to CheckerContext to
explicitly create error nodes. Unless the client provides a custom tag, these
APIs tag the node with the checker's tag -- preventing it from being trimmed.
The generateErrorNode() method creates a sink error node, while
generateNonFatalErrorNode() creates an error node for a path that should
continue being explored.
The intent is that one of these two methods should be used whenever a checker
creates an error node.
This commit updates the checkers to use these APIs. These APIs
(unlike addTransition() and generateSink()) do not take an explicit Pred node.
This is because there are not any error nodes in the checkers that were created
with an explicit different than the default (the CheckerContext's Pred node).
It also changes generateSink() to require state and pred nodes (previously
these were optional) to reduce confusion.
Additionally, there were several cases where checkers did check whether a
generated node could be null; we now explicitly check for null in these places.
This commit also includes a test case written by Ying Yi as part of
http://reviews.llvm.org/D12163 (that patch originally addressed this issue but
was reverted because it introduced false positive regressions).
Differential Revision: http://reviews.llvm.org/D12780
llvm-svn: 247859
This avoids building a fake LLVM IR global variable just to ferry an i32
down into LLVM codegen. It also puts a nail in the coffin of using MS
ABI C++ EH with landingpads, since now we'll assert in the lpad code
when flags are present.
llvm-svn: 247843
ptr in dtor.
Summary:
After destruction, invocation of virtual functions prevented
by poisoning vtable pointer.
Reviewers: eugenis, kcc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D12712
Fixed testing callback emission order to account for vptr.
Poison vtable in either complete or base dtor, depending on
if virtual bases exist. If virtual bases exist, poison in
complete dtor. Otherwise, poison in base.
Remove commented-out block.
llvm-svn: 247762
The root cause here is that ObjCSelectorExpr is an rvalue, yet it can have its
address taken. That's kind of awkward, but fixing this is awkward in other
ways, see https://llvm.org/bugs/show_bug.cgi?id=24774#c16 . For now, just
fix the crash.
llvm-svn: 247740
It is dangerous to do LTO on code with strict-vtable-pointers, because
one module has invariant.group.barriers, and the other one not.
In the future I want to just strip all invariant.group metadata from
vptrs loads/stores and get rid of invariant.group.barrier calls.
http://reviews.llvm.org/D12580
llvm-svn: 247724
Patch adds emission of additional note for 'if' clauses with name modifiers in case if 'if' clause without name modified was specified or 'if' clause with the same name modifier was specified.
llvm-svn: 247706
Patch improves codegen for OpenMP constructs. If the OpenMP region does not have internal 'cancel' construct, a call to 'void __kmpc_barrier()' runtime function is generated for all implicit/explicit barriers. If the region has inner 'cancel' directive, then
```
if (__kmpc_cancel_barrier())
exit from outer construct;
```
code is generated.
Also, the code for 'canellation point' directive is not generated if parent directive does not have 'cancel' directive.
llvm-svn: 247681
In Objective-C, method calls with nil receivers are essentially no-ops. They
do not fault (although the returned value may be garbage depending on the
declared return type and architecture). Programmers are aware of this
behavior and will complain about a false alarm when the analyzer
diagnoses API violations for method calls when the receiver is known to
be nil.
Rather than require each individual checker to be aware of this behavior
and suppress a warning when the receiver is nil, this commit
changes ExprEngineObjC so that VisitObjCMessage skips calling checker
pre/post handlers when the receiver is definitely nil. Instead, it adds a
new event, ObjCMessageNil, that is only called in that case.
The CallAndMessageChecker explicitly cares about this case, so I've changed it
to add a callback for ObjCMessageNil and moved the logic in PreObjCMessage
that handles nil receivers to the new callback.
rdar://problem/18092611
Differential Revision: http://reviews.llvm.org/D12123
llvm-svn: 247653
Overwide bool bitfields have eight bits of storage size, make sure we
take the padding into account when determining whether or not they are
problematic.
llvm-svn: 247651
Previously, in certain cases lax vector conversions could occur between scalar floating-point values and ExtVector types; these conversions would be simple bitcasts. We need to allow them with other vector types to support some common headers, but we don't need them for ExtVector. Preventing them here makes them behave like other operations involving scalars and ExtVectors.
llvm-svn: 247643
There is no __cxa_finalize symbol available on recent Solaris OS
versions, so we need this flag to make non trivial C++ programs run.
Also stop looking for cxa_finalize.o, since it won't be there.
Patch by Xan López!
llvm-svn: 247634
WebAssembly's spec has now been updated to specify some guarantees
about lock free atomic accesses. Update clang to match.
This also updates sig_atomic_t to be 64-bit on wasm64. WebAssembly
does not presently have asynchronous interrupts, but this change is
within the spirit of how they will work if they are added.
Differential Revision: http://reviews.llvm.org/D12862
llvm-svn: 247624
This makes int_fast64_t and int_least64_t the same type as int64_t, and
eliminates a difference between wasm32 and wasm64.
Differential Revision: http://reviews.llvm.org/D12861
llvm-svn: 247622
MS compiler ignores calling convention modifiers for structors. This patch makes
clang do the same (for MS ABI). This fixes PR24595 and makes vswriter.h header
(from Windows SDK 8.1) compilable.
Differential Revision: http://reviews.llvm.org/D12402
llvm-svn: 247619
This is actually needed, otherwise libc won't be added at all. For
instance when building libclang.so all the libc symbols won't be
found, with ld warning about libc being an "implicit dependency".
Patch by Xan López!
llvm-svn: 247603
Current implementation may end up emitting an undefined reference for
an "inline __attribute__((always_inline))" function by generating an
"available_externally alwaysinline" IR function for it and then failing to
inline all the calls. This happens when a call to such function is in dead
code. As the inliner is an SCC pass, it does not process dead code.
Libc++ relies on the compiler never emitting such undefined reference.
With this patch, we emit a pair of
1. internal alwaysinline definition (called F.alwaysinline)
2a. A stub F() { musttail call F.alwaysinline }
-- or, depending on the linkage --
2b. A declaration of F.
The frontend ensures that F.inlinefunction is only used for direct
calls, and the stub is used for everything else (taking the address of
the function, really). Declaration (2b) is emitted in the case when
"inline" is meant for inlining only (like __gnu_inline__ and some
other cases).
This approach, among other nice properties, ensures that alwaysinline
functions are always internal, making it impossible for a direct call
to such function to produce an undefined symbol reference.
This patch is based on ideas by Chandler Carruth and Richard Smith.
llvm-svn: 247494
it's not sufficient to prefer the declaration with more default arguments, or
the one that's visible; they might both be visible, but one of them might have
a visible default argument where the other has a hidden default argument.
llvm-svn: 247486
Current implementation may end up emitting an undefined reference for
an "inline __attribute__((always_inline))" function by generating an
"available_externally alwaysinline" IR function for it and then failing to
inline all the calls. This happens when a call to such function is in dead
code. As the inliner is an SCC pass, it does not process dead code.
Libc++ relies on the compiler never emitting such undefined reference.
With this patch, we emit a pair of
1. internal alwaysinline definition (called F.alwaysinline)
2a. A stub F() { musttail call F.alwaysinline }
-- or, depending on the linkage --
2b. A declaration of F.
The frontend ensures that F.inlinefunction is only used for direct
calls, and the stub is used for everything else (taking the address of
the function, really). Declaration (2b) is emitted in the case when
"inline" is meant for inlining only (like __gnu_inline__ and some
other cases).
This approach, among other nice properties, ensures that alwaysinline
functions are always internal, making it impossible for a direct call
to such function to produce an undefined symbol reference.
This patch is based on ideas by Chandler Carruth and Richard Smith.
llvm-svn: 247465
We used to only select an inheritance model if the pointer to member was
nullptr. Instead, select a model regardless of the member pointer's
value.
N.B. This bug was exposed by making member pointers report true for
isIncompleteType but has been latent since the member pointer scheme's
inception.
llvm-svn: 247464
Add an option (-analyzer-config min-blocks-for-inline-large=14) to control the function
size the inliner considers as large, in relation to "max-times-inline-large". The option
defaults to the original hard coded behaviour, which I believe should be adjustable with
the other inlining settings.
The analyzer-config test has been modified so that the analyzer will reach the
getMinBlocksForInlineLarge() method and store the result in the ConfigTable, to ensure it
is dumped by the debug checker.
A patch by Sean Eveson!
Differential Revision: http://reviews.llvm.org/D12406
llvm-svn: 247463
-force-align-stack.
Also, make changes to the driver so that -mno-stack-realign is no longer
an option exposed to the end-user that disallows stack realignment in
the backend.
Differential Revision: http://reviews.llvm.org/D11815
llvm-svn: 247451
clang modules, if -dwarf-ext-refs (DebugTypesExtRefs) is specified.
This reimplements r247369 in about a third of the amount of code.
Thanks to David Blaikie pointing this out in post-commit review!
llvm-svn: 247432
When uses of personality functions were moved from LandingPadInst to
Function, we forgot to update SimplifyPersonality(). This patch corrects
that.
Note: SimplifyPersonality() is an optimization which replaces
personality functions with the default C++ personality when possible.
Without this update, some ObjC++ projects fail to link against C++
libraries (seeing as the exception ABI had effectively changed).
rdar://problem/22155434
llvm-svn: 247421
It seems that there is small bug, and we can't generate assume loads
when some virtual functions have internal visibiliy
This reverts commit 982bb7d966947812d216489b3c519c9825cacbf2.
llvm-svn: 247332
If target supports TLS all threadprivates are generated as TLS. If target does not support TLS, use runtime calls for proper codegen of threadprivate variables.
llvm-svn: 247273
Currently private copies of captured variables have default alignment. Patch makes private variables to have same alignment as original variables.
llvm-svn: 247260
Currently all variables used in OpenMP regions are captured into a record and passed to outlined functions in this record. It may result in some poor performance because of too complex analysis later in optimization passes. Patch makes to emit outlined functions for parallel-based regions with a list of captured variables. It reduces code for 2*n GEPs, stores and loads at least.
Codegen for task-based regions remains unchanged because runtime requires that all captured variables are passed in captured record.
llvm-svn: 247251
Given a reference to a pointer to member whose class's inheritance model
is unspecified, make sure we come up with an inheritance model in
plausible places. One place we were missing involved LValue to RValue
conversion, another involved unary type traits.
llvm-svn: 247248
This flag causes the compiler to emit bit set entries for functions as well
as runtime bitset checks at indirect call sites. Depends on the new function
bitset mechanism.
Differential Revision: http://reviews.llvm.org/D11857
llvm-svn: 247238
Generating call assume(icmp %vtable, %global_vtable) after constructor
call for devirtualization purposes.
For more info go to:
http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html
Edit:
Fixed version because of PR24479.
After this patch got reverted because of ScalarEvolution bug (D12719)
Merged after John McCall big patch (Added Address).
http://reviews.llvm.org/D11859
llvm-svn: 247199
We know that a reference can always be dereferenced. However, we don't
always know the number of bytes if the reference's pointee type is
incomplete. This case was correctly handled but we didn't consider the
case where the type is complete but we cannot calculate its size for ABI
specific reasons. In this specific case, a member pointer's size is
available only under certain conditions.
This fixes PR24703.
llvm-svn: 247188
The tests in test/CodeGen/arm-target-features.c are currently
passing but warning messages are suppressed. These tests are now
synchronized with the corresponding changes in Target Parser.
This patch will fix the regressions in clang caused by r247136
Differential Revision: http://reviews.llvm.org/D12722
llvm-svn: 247138
Summary:
Currently clang provides no general way to generate nontemporal loads/stores.
There are some architecture specific builtins for doing so (e.g. in x86), but
there is no way to generate non-temporal store on, e.g. AArch64. This patch adds
generic builtins which are expanded to a simple store with '!nontemporal'
attribute in IR.
Differential Revision: http://reviews.llvm.org/D12313
llvm-svn: 247104
This is making our internal build bot fail because it results in extra warnings being
emitted past what should be sink nodes. (There is actually an example of this in the
updated malloc.c test in the reverted commit.)
I'm working on a patch to fix the original issue by adding a new checker API to explicitly
create error nodes. This API will ensure that error nodes are always tagged in order to
prevent them from being reclaimed.
This reverts commit r246188.
llvm-svn: 247103
When -fmodule-format is set to "obj", emit debug info for all types
declared in a module or referenced by a declaration into the module's
object file container.
This patch adds support for Objective-C types and methods.
llvm-svn: 247068
When -fmodule-format is set to "obj", emit debug info for all types
declared in a module or referenced by a declaration into the module's
object file container.
This patch adds support for C and C++ types.
llvm-svn: 247049
Summary:
If class or struct has not declared a destructor,
no destructor is emitted, and members are not poisoned
after destruction. This case highlights bug in current
implementation of use-after-dtor poisoning (detailed
in https://github.com/google/sanitizers/issues/596).
Reviewers: eugenis, kcc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D12616
Only check simplest object for existence of sanitizing callback.
Rename test.
llvm-svn: 247025
instruction used the ReturnValue as pointer operand or value operand. This
led to wrong code gen - in later stages (load-store elision code) the found
store and its operand would be erased, causing ReturnValue to become a <badref>.
The patch adds a check that makes sure that ReturnValue is a pointer operand of
store instruction. Regression test is also added.
This fixes PR24386.
Differential Revision: http://reviews.llvm.org/D12400
llvm-svn: 247003
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
Apparently there are many cast kinds that may cause implicit pointer
arithmetic to happen. In light of this, the cast ignoring logic
introduced in r246877 has been changed to only ignore a small set of
cast kinds, and a test for this behavior has been added.
Thanks to Richard for catching this before it became a bug report. :)
llvm-svn: 246890
We were crashing in CodeGen given input like this:
int self_alias(void) __attribute__((weak, alias("self_alias")));
such a self-alias is invalid, but instead of diagnosing the situation, we'd
proceed to produce IR for both the function declaration and the alias. Because
we already had a function named 'self_alias', the alias could not be named the
same thing, and so LLVM would pick a different name ('self_alias1' for example)
for that value. When we later called CodeGenModule::checkAliases, we'd look up
the IR value corresponding to the alias name, find the function declaration
instead, and then assert in a cast to llvm::GlobalAlias. The easiest way to prevent
this is simply to avoid creating the wrongly-named alias value in the first
place and issue the diagnostic there (instead of in checkAliases). We detect a
related cycle case in CodeGenModule::EmitAliasDefinition already, so this just
adds a second such check.
Even though the other test cases for this 'alias definition is part of a cycle'
diagnostic are in test/Sema/attr-alias-elf.c, I've added a separate regression
test for this case. This is because I can't add this check to
test/Sema/attr-alias-elf.c without disturbing the other test cases in that
file. In order to avoid construction of the bad IR values, this diagnostic
is emitted from within CodeGenModule::EmitAliasDefinition (and the relevant
declaration is not added to the Aliases vector). The other cycle checks are
done within the CodeGenModule::checkAliases function based on the Aliases
vector, called from CodeGenModule::Release. However, if there have been errors
earlier, HandleTranslationUnit does not call Release, and so checkAliases is
never called, and so none of the other diagnostics would be produced.
Fixes PR23509.
llvm-svn: 246882
This fixes an issue raised in D12412, where we generated invalid IR.
Thanks to Vedant Kumar for coming up with the initial work around.
Differential Revision: http://reviews.llvm.org/D12412
llvm-svn: 246880
Improvements:
- For all types, we would give up in a case such as:
__builtin_object_size((char*)&foo, N);
even if we could provide an answer to
__builtin_object_size(&foo, N);
We now provide the same answer for both of the above examples in all
cases.
- For type=1|3, we now support subobjects with unknown bases, as long
as the designator is valid.
Thanks to Richard Smith for the review + design planning.
Review: http://reviews.llvm.org/D12169
llvm-svn: 246877
They might technically have external linkage, but it still doesn't make sense
for the user to try and export such variables. This matches MSVC's and MinGW's
behaviour.
llvm-svn: 246864
If we build with -Werror=implicit-function-declaration, only implicit
function declarations of non-library functions throw compiler errors.
For library functions, we only produce a warning. There is no way to
promote both of these cases to an error without promoting other
warnings.
It makes little sense to introduce an additional compiler flag just to
control this specific warning. In my opinion it should just be part of
the same group.
llvm-svn: 246857
Some of instantiation-dependent expressions could cause false diagnostic to be emitted about unsupported atomic constructs. Relaxed rules for detection of incorrect expressions.
llvm-svn: 246853
Fix processing of shared variables with reference types in OpenMP constructs. Previously, if the variable was not marked in one of the private clauses, the reference to this variable was emitted incorrectly and caused an assertion later.
llvm-svn: 246846
Summary:
Dtor sanitization handled amidst other dtor cleanups,
between cleaning bases and fields. Sanitizer call pushed onto
stack of cleanup operations.
Reviewers: eugenis, kcc
Differential Revision: http://reviews.llvm.org/D12022
Refactoring dtor sanitizing emission order.
- Support multiple inheritance by poisoning after
member destructors are invoked, and before base
class destructors are invoked.
- Poison for virtual destructor and virtual bases.
- Repress dtor aliasing when sanitizing in dtor.
- CFE test for dtor aliasing, and repression of aliasing in dtor
code generation.
- Poison members on field-by-field basis, with collective poisoning
of trivial members when possible.
- Check msan flags and existence of fields, before dtor sanitizing,
and when determining if aliasing is allowed.
- Testing sanitizing bit fields.
llvm-svn: 246815
This implements basic support for compiling (though not yet assembling
or linking) for a WebAssembly target. Note that ABI details are not yet
finalized, and may change.
Differential Revision: http://reviews.llvm.org/D12002
llvm-svn: 246814
It used to work, but was accidentally broken by r179769.
The issue with decayed types was fixed by r190796.
So this patch partially reverts r179769, and adds more tests.
This also fixes PR 18669.
Patch by Sergey Kalinichev.
llvm-svn: 246778
Summary: The command line options for these are -Wa,--trap and -Wa,--break.
Patch by Scott Egerton.
Reviewers: vkalintiris, dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11676
llvm-svn: 246765
The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be
used as a functon argument or return type (ACLE 1.1 did not).
The current public release of the AAPCS (2.09) states that __fp16 values
should be converted to single-precision before being passed or returned,
but AAPCS 2.10 (to be released shortly) changes this, so that they are
passed in the least-significant 16 bits of either a GPR (for base AAPCS)
or a single-precision register (for AAPCS-VFP). This does not change how
arguments are passed if they get passed on the stack.
This patch brings clang up to compliance with the latest versions of
both of these specs.
We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always
been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support
the alternative format).
llvm-svn: 246764
Original commit message:
[ARM] Allow passing/returning of __fp16 arguments
The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be
used as a functon argument or return type (ACLE 1.1 did not).
The current public release of the AAPCS (2.09) states that __fp16 values
should be converted to single-precision before being passed or returned,
but AAPCS 2.10 (to be released shortly) changes this, so that they are
passed in the least-significant 16 bits of either a GPR (for base AAPCS)
or a single-precision register (for AAPCS-VFP). This does not change how
arguments are passed if they get passed on the stack.
This patch brings clang up to compliance with the latest versions of
both of these specs.
We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always
been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support
the alternative format).
llvm-svn: 246760
The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be
used as a functon argument or return type (ACLE 1.1 did not).
The current public release of the AAPCS (2.09) states that __fp16 values
should be converted to single-precision before being passed or returned,
but AAPCS 2.10 (to be released shortly) changes this, so that they are
passed in the least-significant 16 bits of either a GPR (for base AAPCS)
or a single-precision register (for AAPCS-VFP). This does not change how
arguments are passed if they get passed on the stack.
This patch brings clang up to compliance with the latest versions of
both of these specs.
We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always
been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support
the alternative format).
llvm-svn: 246755
Fixed codegen for extended format of 'if' clauses with special 'directive-name-modifier' + ast-print tests for extended format of 'if' clause.
llvm-svn: 246748
OpenMP 4.1 added special 'directive-name-modifier' to the 'if' clause.
Format of 'if' clause is as follows:
```
if([ directive-name-modifier :] scalar-logical-expression)
```
The restriction rules are also changed.
1. If any 'if' clause on the directive includes a 'directive-name-modifier' then all 'if' clauses on the directive must include a 'directive-name-modifier'.
2. At most one 'if' clause without a 'directive-name-modifier' can appear on the directive.
3. At most one 'if' clause with some particular 'directive-name-modifier' can appear on the directive.
'directive-name-modifier' is important for combined directives and allows to separate conditions in 'if' clause for simple sub-directives in combined directive. This 'directive-name-modifier' identifies the sub-directive to which this 'if' clause must be applied.
llvm-svn: 246747
Summary:
Do not include default sanitizer blacklists into -M/-MM/-MD/-MMD output.
Introduce a frontend option -fdepfile-entry, and only insert them
for the user-defined sanitizer blacklists. In frontend, grab ExtraDeps
from -fdepfile-entry, instead of -fsanitize-blacklist.
Reviewers: rsmith, pcc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D12544
llvm-svn: 246700
This patch depends on r246688 (D12341).
The goal is to make LLVM generate different code for these functions for a target that
has cheap branches (see PR23827 for more details):
int foo();
int normal(int x, int y, int z) {
if (x != 0 && y != 0) return foo();
return 1;
}
int crazy(int x, int y) {
if (__builtin_unpredictable(x != 0 && y != 0)) return foo();
return 1;
}
Differential Revision: http://reviews.llvm.org/D12458
llvm-svn: 246699
TagDecls (structs, enums, etc.) may have the same name for linkage
purposes of one another; to disambiguate, we add a number to the mangled
named. However, we didn't do this if the TagDecl has a pseudo-name for
linkage purposes (it was defined alongside a DeclaratorDecl or a
TypeNameDecl).
This fixes PR24651.
llvm-svn: 246659
Summary:
`OpaqueValueExpr`s may not have a source expression (as in the case when
they are created due to a default argument error).
This can cause an assertion failure in `TransformOpaqueValueExpr` during
template instantiation.
This patch fixes the assertion failure.
Reviewers: hfinkel, rsmith
Subscribers: fraggamuffin, cfe-commits
Differential Revision: http://reviews.llvm.org/D11582
Patch by Rachel Craik!
llvm-svn: 246600
r246546, with a workaround for an MSVC 2013 miscompile and an MSVC 2015
rejects-valid.
Original commit message:
[modules] Rework serialized DeclContext lookup table management. Instead of
walking the loaded ModuleFiles looking for lookup tables for the context, store
them all in one place, and merge them together if we find we have too many
(currently, more than 4). If we do merge, include the merged form in our
serialized lookup table, so that downstream readers never need to look at our
imports' tables.
This gives a huge performance improvement to builds with very large numbers of
modules (in some cases, more than a 2x speedup was observed).
llvm-svn: 246582
David Majnemer