Much to my surprise, '-disable-llvm-optzns' which I thought was the
magical flag I wanted to get at the raw LLVM IR coming out of Clang
deosn't do that. It still runs some passes over the IR. I don't want
that, I really want the *raw* IR coming out of Clang and I strongly
suspect everyone else using it is in the same camp.
There is actually a flag that does what I want that I didn't know about
called '-disable-llvm-passes'. I suspect many others don't know about it
either. It both does what I want and is much simpler.
This removes the confusing version and makes that spelling of the flag
an alias for '-disable-llvm-passes'. I've also moved everything in Clang
to use the 'passes' spelling as it seems both more accurate (*all* LLVM
passes are disabled, not just optimizations) and much easier to remember
and spell correctly.
This is part of simplifying how Clang drives LLVM to make it cleaner to
wire up to the new pass manager.
Differential Revision: https://reviews.llvm.org/D28047
llvm-svn: 290392
program
Offload related code is not quite ready yet, but some simple examples
must not crash the compiler. Patch fixes the problem in offloading code
with exceptions.
llvm-svn: 290364
This is a recommit of r290149, which was reverted in r290169 due to msan
failures. msan was failing because we were calling
`isMostDerivedAnUnsizedArray` on an invalid designator, which caused us
to read uninitialized memory. To fix this, the logic of the caller of
said function was simplified, and we now have a `!Invalid` assert in
`isMostDerivedAnUnsizedArray`, so we can catch this particular bug more
easily in the future.
Fingers crossed that this patch sticks this time. :)
Original commit message:
This patch does three things:
- Gives us the alloc_size attribute in clang, which lets us infer the
number of bytes handed back to us by malloc/realloc/calloc/any user
functions that act in a similar manner.
- Teaches our constexpr evaluator that evaluating some `const` variables
is OK sometimes. This is why we have a change in
test/SemaCXX/constant-expression-cxx11.cpp and other seemingly
unrelated tests. Richard Smith okay'ed this idea some time ago in
person.
- Uniques some Blocks in CodeGen, which was reviewed separately at
D26410. Lack of uniquing only really shows up as a problem when
combined with our new eagerness in the face of const.
llvm-svn: 290297
This change introduces UsingPackDecl as a marker for the set of UsingDecls
produced by pack expansion of a single (unresolved) using declaration. This is
not strictly necessary (we just need to be able to map from the original using
declaration to its expansions somehow), but it's useful to maintain the
invariant that each declaration reference instantiates to refer to one
declaration.
This is a re-commit of r290080 (reverted in r290092) with a fix for a
use-after-lifetime bug.
llvm-svn: 290203
This reverts commit r290171. It triggers a bunch of warnings, because
the new enumerator isn't handled in all switches. We want a warning-free
build.
Replied on the commit with more details.
llvm-svn: 290173
Summary: Enabling the compression of CLK_NULL_QUEUE to variable of type queue_t.
Reviewers: Anastasia
Subscribers: cfe-commits, yaxunl, bader
Differential Revision: https://reviews.llvm.org/D27569
llvm-svn: 290171
This commit fails MSan when running test/CodeGen/object-size.c in
a confusing way. After some discussion with George, it isn't really
clear what is going on here. We can make the MSan failure go away by
testing for the invalid bit, but *why* things are invalid isn't clear.
And yet, other code in the surrounding area is doing precisely this and
testing for invalid.
George is going to take a closer look at this to better understand the
nature of the failure and recommit it, for now backing it out to clean
up MSan builds.
llvm-svn: 290169
This patch does three things:
- Gives us the alloc_size attribute in clang, which lets us infer the
number of bytes handed back to us by malloc/realloc/calloc/any user
functions that act in a similar manner.
- Teaches our constexpr evaluator that evaluating some `const` variables
is OK sometimes. This is why we have a change in
test/SemaCXX/constant-expression-cxx11.cpp and other seemingly
unrelated tests. Richard Smith okay'ed this idea some time ago in
person.
- Uniques some Blocks in CodeGen, which was reviewed separately at
D26410. Lack of uniquing only really shows up as a problem when
combined with our new eagerness in the face of const.
Differential Revision: https://reviews.llvm.org/D14274
llvm-svn: 290149
This change introduces UsingPackDecl as a marker for the set of UsingDecls
produced by pack expansion of a single (unresolved) using declaration. This is
not strictly necessary (we just need to be able to map from the original using
declaration to its expansions somehow), but it's useful to maintain the
invariant that each declaration reference instantiates to refer to one
declaration.
llvm-svn: 290080
The UBSAN runtime is built static on Windows. This requires that we give local
storage always. This impacts Windows where the linker would otherwise have to
generate a thunk to access the symbol via the IAT. This should repair the
windows clang build bots.
llvm-svn: 289829
Unfortunately _setjmp3 can be both import or local. The ASAN tests try to
emulate the flags which makes this harder to detect. Rely on the linker
creating or using thunks here instead. Should repair the ASAN windows bots.
llvm-svn: 289783
Properly attribute DLL storage to runtime functions. When generating the
runtime function, scan for an existing declaration which may provide an explicit
declaration (local storage) or a DLL import or export storage from the user.
Honour that if available. Otherwise, if building with a local visibility of the
public or standard namespaces (-flto-visibility-public-std), give the symbols
local storage (it indicates a /MT[d] link, so static runtime). Otherwise,
assume that the link is dynamic, and give the runtime function dllimport
storage.
This allows for implementations to get the correct storage as long as they are
properly declared, the user to override the import storage, and in case no
explicit storage is given, use of the import storage.
llvm-svn: 289776
BackendUtil.cpp uses llvm::SmallSet but did not include the header. It was
included indirectly, but this will change once the AssumptionCache is removed.
NFC.
llvm-svn: 289752
Summary:
We used to create SampleProfileLoader pass in clang. This makes LTO/ThinLTO unable to add this pass in the linker plugin. This patch moves the SampleProfileLoader pass creation from
clang to llvm pass manager builder.
Reviewers: tejohnson, davidxl, dnovillo
Subscribers: mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D27744
llvm-svn: 289715
This way it will be easier to expand DIFile (e.g., to contain checksum) without the need to modify the createCompileUnit() API.
Reviewers: cfe-commits, rnk
Differential Revision: https://reviews.llvm.org/D27763
llvm-svn: 289701
Summary:
We used to create SampleProfileLoader pass in clang. This makes LTO/ThinLTO unable to add this pass in the linker plugin. This patch moves the SampleProfileLoader pass creation from
clang to llvm pass manager builder.
Reviewers: tejohnson, davidxl, dnovillo
Subscribers: mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D27744
llvm-svn: 289670
At least the plugin used by the LibreOffice build
(<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly
uses those members (through inline functions in LLVM/Clang include files in turn
using them), but they are not exported by utils/extract_symbols.py on Windows,
and accessing data across DLL/EXE boundaries on Windows is generally
problematic.
Differential Revision: https://reviews.llvm.org/D26671
llvm-svn: 289647
copy constructors of classes with array members, instead using
ArrayInitLoopExpr to represent the initialization loop.
This exposed a bug in the static analyzer where it was unable to differentiate
between zero-initialized and unknown array values, which has also been fixed
here.
llvm-svn: 289618
This annotation allows the optimizer to split vtable groups, as permitted by
a change to the Itanium ABI [1] that prevents compilers from adjusting virtual
table pointers between virtual tables.
[1] https://github.com/MentorEmbedded/cxx-abi/pull/7
Differential Revision: https://reviews.llvm.org/D24431
llvm-svn: 289585
In a future change, this representation will allow us to use the new inrange
annotation on getelementptr to allow the optimizer to split vtable groups.
Differential Revision: https://reviews.llvm.org/D22296
llvm-svn: 289584
This adds a way for us to version any UBSan handler by itself.
The patch overrides D21289 for a better implementation (we're able to
rev up a single handler).
After this, then we can land a slight modification of D19667+D19668.
We probably don't want to keep all the versions in compiler-rt (maybe we
want to deprecate on one release and remove the old handler on the next
one?), but with this patch we will loudly fail to compile when mixing
incompatible handler calls, instead of silently compiling and then
providing bad error messages.
Reviewers: kcc, samsonov, rsmith, vsk
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D21695
llvm-svn: 289444
initialization of each array element:
* ArrayInitLoopExpr is a prvalue of array type with two subexpressions:
a common expression (an OpaqueValueExpr) that represents the up-front
computation of the source of the initialization, and a subexpression
representing a per-element initializer
* ArrayInitIndexExpr is a prvalue of type size_t representing the current
position in the loop
This will be used to replace the creation of explicit index variables in lambda
capture of arrays and copy/move construction of classes with array elements,
and also C++17 structured bindings of arrays by value (which inexplicably allow
copying an array by value, unlike all of C++'s other array declarations).
No uses of these nodes are introduced by this change, however.
llvm-svn: 289413
On some Apple platforms, the ObjC BOOL type is defined as a signed char.
When performing instrumentation for -fsanitize=bool, we'd like to treat
the range of BOOL like it's always {0, 1}. While we can't change clang's
IRGen for char-backed BOOL's due to ABI compatibility concerns, we can
teach ubsan to catch potential abuses of this type.
rdar://problem/29502773
Differential Revision: https://reviews.llvm.org/D27607
llvm-svn: 289290
In amdgcn target, null pointers in global, constant, and generic address space take value 0 but null pointers in private and local address space take value -1. Currently LLVM assumes all null pointers take value 0, which results in incorrectly translated IR. To workaround this issue, instead of emit null pointers in local and private address space, a null pointer in generic address space is emitted and casted to local and private address space.
Tentative definition of global variables with non-zero initializer will have weak linkage instead of common linkage since common linkage requires zero initializer and does not have explicit section to hold the non-zero value.
Virtual member functions getNullPointer and performAddrSpaceCast are added to TargetCodeGenInfo which by default returns ConstantPointerNull and emitting addrspacecast instruction. A virtual member function getNullPointerValue is added to TargetInfo which by default returns 0. Each target can override these virtual functions to get target specific null pointer and the null pointer value for specific address space, and perform specific translations for addrspacecast.
Wrapper functions getNullPointer is added to CodegenModule and getTargetNullPointerValue is added to ASTContext to facilitate getting the target specific null pointers and their values.
This change has no effect on other targets except amdgcn target. Other targets can provide support of non-zero null pointer in a similar way.
This change only provides support for non-zero null pointer for C and OpenCL. Supporting for other languages will be added later incrementally.
Differential Revision: https://reviews.llvm.org/D26196
llvm-svn: 289252
This patch is to implement sema and parsing for 'teams distribute parallel for' pragma.
Differential Revision: https://reviews.llvm.org/D27345
llvm-svn: 289179
Summary:
Partial fix for PR26619.
Prior to this change, a DIGlobalVariable corresponding to a static
const was marked with an expression corresponding to its constant
value only if it is of integral type. With this change, we now do the
same if it is of __fp16, float, or double type (that is,
floating-point types that do not exceed 64 bits in size, and hence are
supported easily by the existing LLVM machinery for creating constant
expressions in debug info).
Reviewers: llvm-commits
Differential Revision: https://reviews.llvm.org/D27549
llvm-svn: 289094
The problem only happen on window ( A MS-ABI issuer )
The nature of the problem is virtual base dtor called more than it is needed after exception throw in inheriting base class(with virtual bases) ctor.
The root problem is when throw happen, not all virtual base classes have been contructed, so not all virtual base dtors are need to call for ehcleanup.
clang has code to handle vbase initialization: basically add check for "complete object flag" before call to v-base ctor.
But that part is missing for cleanup code.
To fix this add similar code as v-base init to cleanup code, same algorithm.
1> Add new routine:
EmitDtorCompleteObjectHandler
With corresponding to EmitCtorCompleteObjectHandler
2> In the EmitDestructorCal
Call EmitDtorCompleteObjectHandler when generate ehcleanup inside ctor.
Just add check for "complete object flag" before call to v-base dtor.
Without my change:
ehcleanup: ; preds = %ctor.skip_vbases
%13 = cleanuppad within none [], !dbg !66
%14 = bitcast %struct.class_0* %this1 to i8*, !dbg !66
%15 = getelementptr inbounds i8, i8* %14, i64 8, !dbg !66
%16 = bitcast i8* %15 to %struct.class_2*, !dbg !66
call void @"\01??1class_2@@UEAA@XZ"(%struct.class_2* %16) #6 [ "funclet"(token
%13) ], !dbg !66
cleanupret from %13 unwind to caller, !dbg !66
with my change:
ehcleanup: ; preds = %ctor.skip_vbases
%13 = cleanuppad within none [], !dbg !66
%14 = bitcast %struct.class_0* %this1 to i8*, !dbg !66
%15 = getelementptr inbounds i8, i8* %14, i64 8, !dbg !66
%16 = bitcast i8* %15 to %struct.class_2*, !dbg !66
%is_complete_object4 = icmp ne i32 %is_most_derived2, 0, !dbg !66
br i1 %is_complete_object4, label %Dtor.dtor_vbase, label %Dtor.skip_vbase, !d
bg !66
Dtor.dtor_vbase: ; preds = %ehcleanup
call void @"\01??1class_2@@UEAA@XZ"(%struct.class_2* %16) #6 [ "funclet"(token
%13) ], !dbg !66
br label %Dtor.skip_vbase, !dbg !66
Dtor.skip_vbase: ; preds = %Dtor.dtor_vbase, %ehcleanup
cleanupret from %13 unwind to caller, !dbg !66
Please let me know you need more info.
Patch by Jennifer Yu.
Differential Revision: https://reviews.llvm.org/D27358
llvm-svn: 288869
When an object of class type is initialized from a prvalue of the same type
(ignoring cv qualifications), use the prvalue to initialize the object directly
instead of inserting a redundant elidable call to a copy constructor.
llvm-svn: 288866
When emitting RTTI for EH only, we would mark the locally defined (LinkOnceODR)
RTTI definition as dllimport, which is incorrect. Ensure that if we are
generating the type information for EH only, it is marked as LinkOnceODR and we
do not make it dllimport.
llvm-svn: 288721
When a C++ record is marked with dllexport mark both the typeinfo and the
typeinfo name as being exported. Handle dllimport as the inverse. This applies
to the itanium environment and not the MinGW environment.
llvm-svn: 288546
have the same size.
This fixes an asset that is triggered when an address of a boolean
variable is passed to __builtin_arm_ldrex or __builtin_arm_strex.
rdar://problem/29269006
llvm-svn: 288404
This patch is to implement sema and parsing for 'teams distribute parallel for simd' pragma.
Differential Revision: https://reviews.llvm.org/D27084
llvm-svn: 288294
performed at the CodeGenModule level.
Would be NFC except we now also use a different uniquing structure so
that we don't get spurious conflicts if you ask for both an NSString
and a CFString for the same content (which is possible with builtins).
llvm-svn: 288287
Other AST consumers can deserialize interesting decls that we might
codegen, but they won't make it to the final object file and can trigger
assertions in debug information generation after finalization.
llvm-svn: 288221
Avoid using shortcut for const qualified non-constant address space
aggregate variables while generating them on the stack such that
the alloca object is used instead of a global variable containing
initializer.
Review: https://reviews.llvm.org/D27109
llvm-svn: 288163
This solves PR23715 in a way that is compatible with LTO.
MSVC supports jumping to source-level labels and between inline asm
blocks, but we don't.
Also revert the old solution, r255201, which was to mark these calls as
noduplicate.
llvm-svn: 288059
Summary:
We don't need a side table in ASTContext to hold CXXDefaultArgExprs. The
important part of building the CXXDefaultArgExprs was to ODR use the
default argument expressions, not to make AST nodes. Refactor the code
to only check the default argument, and remove the side table in
ASTContext which wasn't being serialized.
Fixes PR31121
Reviewers: thakis, rsmith, majnemer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D27007
llvm-svn: 287774
Currently, TargetLibraryInfoWrapperPass is inserted by PMBuilder.
However, some passes are inserted manually before the PMBuilder
ones - if any of them happens to use TargetLibraryInfoWrapperPass,
it'll get a default-constructed one, with an unknown target triple.
This happens to InstrProfiling in D21736, breaking it.
Differential Revision: http://reviews.llvm.org/D21737
llvm-svn: 287688
This is needed because whether the constructor is deleted can control whether
we pass structs by value directly.
To fix this properly we probably want a more direct way for CodeGen to ask
whether the constructor was deleted.
Fixes PR31049.
Differential Revision: https://reviews.llvm.org/D26822
llvm-svn: 287600
Summary:
This makes it explicit that ownership is taken. Also replace all `new`
with make_unique<> at call sites.
Reviewers: anemet
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D26884
llvm-svn: 287449
StartFunction enters a release cleanup for ns_consumed arguments in
ARC, so we need to balance that somehow. We could teach StartFunction
that it's emitting a delegating function, so that the cleanup is
unnecessary, but that would be invasive and somewhat fraught. We could
balance the consumed argument with an extra retain, but clearing the
original variable should be easier to optimize and avoid some extra work
at -O0. And there shouldn't be any difference as long as nothing else
uses the argument, which should always be true for the places we emit
delegate arguments.
Fixes PR 27887.
llvm-svn: 287291
If 'omp cancel' construct is used in a worksharing construct it may
cause hanging of the software in case if reduction clause is used. Patch fixes this problem by avoiding extra reduction processing for branches that were canceled.
llvm-svn: 287227
Summary:
this is to prevent a situation when a pointer is invalid or null,
but we get to reading from vtable before we can check that
(possibly causing a segfault without a good diagnostics).
Reviewers: pcc
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D26559
llvm-svn: 287181
Instead of always displaying the mangled name, try to do better
and get something closer to regular functions.
Recommit r287039 (that was reverted in r287039) with a tweak to
be more generic, and test fixes!
Differential Revision: https://reviews.llvm.org/D26522
llvm-svn: 287085
Summary:
r286944 introduced bugs detected by ASAN as use-after-return.
r287025 have not fixed them completely.
This reverts commit r286944 and r287025.
Reviewers: ABataev
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D26720
llvm-svn: 287069
Instead of always displaying the mangled name, try to do better
and get something closer to regular functions.
Differential Revision: https://reviews.llvm.org/D26522
llvm-svn: 287039
This patch implements all the overloads for vec_xl_be and vec_xst_be. On BE,
they behaves exactly the same with vec_xl and vec_xst, therefore they are
simply implemented by defining a matching macro. On LE, they are implemented
by defining new builtins and intrinsics. For int/float/long long/double, it
is just a load (lxvw4x/lxvd2x) or store(stxvw4x/stxvd2x). For char/char/short,
we also need some extra shuffling before or after call the builtins to get the
desired BE order. For int128, simply call vec_xl or vec_xst.
llvm-svn: 286971
If 'omp cancel' construct is used in a worksharing construct it may cause
hanging of the software in case if reduction clause is used. Patch fixes
this problem by avoiding extra reduction processing for branches that
were canceled.
llvm-svn: 286944
Make handling integer parameters more flexible:
- For the number of events argument allow to pass larger
integers than 32 bits as soon as compiler can prove that
the range fits in 32 bits. If not, the diagnostic will be given.
- Change type of the arguments specifying the sizes of
the corresponding block arguments to be size_t.
Review: https://reviews.llvm.org/D26509
llvm-svn: 286849
- Accept NULL pointer as a valid parameter value for clk_event.
- Generate clk_event_t arguments of internal
__enqueue_kernel_XXX function as pointers in generic address space.
Review: https://reviews.llvm.org/D26507
llvm-svn: 286836
It doesn't make sense to use the target's address space ids in this context as
this is metadata that should be referring to the "logical" OpenCL address spaces.
For flat AS machines like all "CPUs" in general, the logical AS info gets lost as
there's only one address space (0).
This commit changes the logic such that we always use the SPIR address space
ids for the argument metadata. It thus allows implementing the clGetKernelArgInfo()
and the other detection needs.
https://reviews.llvm.org/D26157
llvm-svn: 286819
This introduces a function annotation that disables TSan checking for the
function at run time. The benefit over attribute((no_sanitize("thread")))
is that the accesses within the callees will also be suppressed.
The motivation for this attribute is a guarantee given by the objective C
language that the calls to the reference count decrement and object
deallocation will be synchronized. To model this properly, we would need to
intercept all ref count decrement calls (which are very common in ObjC due
to use of ARC) and also every single message send. Instead, we propose to
just ignore all accesses made from within dealloc at run time. The main
downside is that this still does not introduce any synchronization, which
means we might still report false positives if the code that relies on this
synchronization is not executed from within dealloc. However, we have not
seen this in practice so far and think these cases will be very rare.
(This problem is similar in nature to https://reviews.llvm.org/D21609;
unfortunately, the same solution does not apply here.)
Differential Revision: https://reviews.llvm.org/D25857
llvm-svn: 286672
The change in D26502 splits ReaderWriter.h, which contains the APIs
into both the BitReader and BitWriter libraries, into BitcodeReader.h
and BitcodeWriter.h.
Change clang uses to the appropriate split header(s).
llvm-svn: 286567
function. In that case, there is no requirement that the callee is actually
defined, and the code may in fact be valid and have defined behavior if the
virtual call is unreachable.
llvm-svn: 286534
Since array parameters decay to pointers, '_Nullable' and friends
should be available for use there as well. This is especially
important for parameters that are typedefs of arrays. The unsugared
syntax for this follows the syntax for 'static'-sized arrays in C:
void test(int values[_Nullable]);
This syntax was previously accepted but the '_Nullable' (and any other
attributes) were silently discarded. However, applying '_Nullable' to
a typedef was previously rejected and is now accepted; therefore, it
may be necessary to test for the presence of this feature:
#if __has_feature(nullability_on_arrays)
One important change here is that DecayedTypes don't always
immediately contain PointerTypes anymore; they may contain an
AttributedType instead. This only affected one place in-tree, so I
would guess it's not likely to cause problems elsewhere.
This commit does not change -Wnullability-completeness just yet. I
want to think about whether it's worth doing something special to
avoid breaking existing clients that compile with -Werror. It also
doesn't change '#pragma clang assume_nonnull' behavior, which
currently treats the following two declarations as equivalent:
#pragma clang assume_nonnull begin
void test(void *pointers[]);
#pragma clang assume_nonnull end
void test(void * _Nonnull pointers[]);
This is not the desired behavior, but changing it would break
backwards-compatibility. Most likely the best answer is going to be
adding a new warning.
Part of rdar://problem/25846421
llvm-svn: 286519
can be used to improve the locations when generating remarks for loops.
Depends on the companion LLVM change r286227.
Patch by Florian Hahn.
Differential Revision: https://reviews.llvm.org/D25764
llvm-svn: 286456
Thunks are artificial and have no corresponding source location except for the
line number on the DISubprogram, which is marked as artificial.
<rdar://problem/11941095>
llvm-svn: 286400
Add a check to the DeclCache before emitting debug info for a
GlobalVariable a second time and just attach the previsously created one to it.
<rdar://problem/26721101>
llvm-svn: 286322
Unique ownership is just one possible ownership pattern for the memory buffer
underlying the bitcode reader. In practice, as this patch shows, ownership can
often reside at a higher level. With the upcoming change to allow multiple
modules in a single bitcode file, it will no longer be appropriate for
modules to generally have unique ownership of their memory buffer.
The C API exposes the ownership relation via the LLVMGetBitcodeModuleInContext
and LLVMGetBitcodeModuleInContext2 functions, so we still need some way for
the module to own the memory buffer. This patch does so by adding an owned
memory buffer field to Module, and using it in a few other places where it
is convenient.
Differential Revision: https://reviews.llvm.org/D26384
llvm-svn: 286214
As proposed on llvm-dev:
http://lists.llvm.org/pipermail/llvm-dev/2016-October/106630.html
Move block info block state to a new class, BitstreamBlockInfo.
Clients may set the block info for a particular cursor with the
BitstreamCursor::setBlockInfo() method.
At this point BitstreamReader is not much more than a container for an
ArrayRef<uint8_t>, so remove it and replace all uses with direct uses
of memory buffers.
Differential Revision: https://reviews.llvm.org/D26259
llvm-svn: 286207
Summary: Use -fsanitize-recover instead of -mllvm -msan-keep-going: pass -fsanitize-recover value to msan.
Reviewers: eugenis
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D26354
Patch by Aleksey Shlyapnikov.
llvm-svn: 286148
constructs.
For __real/__imag unary expressions clang emits lvalue with the
associated type from the original complex expression, but not the
underlying builtin integer or float type. This causes crash in codegen
for atomic constructs, if __real/__imag expression are used in atomic
constructs.
llvm-svn: 286129
The fixed code is basically identical to the same loop below, which
might indicate an opportunity for refactoring. I just wanted to fix
the use-of-temporary issue.
Caught by adding a similar check to StringRef as r283798 did for
ArrayRef. I'll be upstreaming that soon.
Reviewed by Vedant Kumar as https://reviews.llvm.org/D26317.
llvm-svn: 286122
After some changes in codegen capturing of VLA variables in OpenMP regions was broken, causing compiler crash. Patch fixes this issue.
llvm-svn: 286103
After some changes in codegen capturing of VLA variables in OpenMP
regions was broken, causing compiler crash. Patch fixes this issue.
llvm-svn: 286098
* if the base is produced by a series of derived-to-base conversions, check
the expression inside them when looking for an expression with a known
dynamic type
* step past MaterializeTemporaryExprs when checking for a known dynamic type
* when checking for a known dynamic type, treat all class prvalues as having
a known dynamic type after skipping all relevant rvalue subobject
adjustments
* treat callees formed by pointer-to-member access for a non-reference member
type like callees formed by member access.
llvm-svn: 285954
Looks like CurFn's name outlives FunctionName, so we can just pass
StringRefs around rather than going from a StringRef to a std::string
to a const char* to a StringRef.
llvm-svn: 285873
This patch implements the register call calling convention, which ensures
as many values as possible are passed in registers. CodeGen changes
were committed in https://reviews.llvm.org/rL284108.
Differential Revision: https://reviews.llvm.org/D25204
llvm-svn: 285849
As proposed on llvm-dev:
http://lists.llvm.org/pipermail/llvm-dev/2016-October/106595.html
This change also fixes an API oddity where BitstreamCursor::Read() would
return zero for the first read past the end of the bitstream, but would
report_fatal_error for subsequent reads. Now we always report_fatal_error
for all reads past the end. Updated clients to check for the end of the
bitstream before reading from it.
I also needed to add padding to the invalid bitcode tests in
test/Bitcode/. This is because the streaming interface was not checking that
the file size is a multiple of 4.
Differential Revision: https://reviews.llvm.org/D26219
llvm-svn: 285773
Certain OpenCL builtin functions are supposed to be executed by all threads in a work group or sub group. Such functions should not be made divergent during transformation. It makes sense to mark them with convergent attribute.
The adding of convergent attribute is based on Ettore Speziale's work and the original proposal and patch can be found at https://www.mail-archive.com/cfe-commits@lists.llvm.org/msg22271.html.
Differential Revision: https://reviews.llvm.org/D25343
llvm-svn: 285725
on cxx-abi-dev (thread starting 2016-10-11). This is currently hidden behind a
cc1-only -m flag, pending discussion of how best to deal with language changes
that require use of new symbols from the ABI library.
llvm-svn: 285664
Summary: Setting constant address space for global constants used for memcpy-initialization of arrays.
Patch by Alexey Sotkin.
Reviewers: bader, yaxunl, Anastasia
Subscribers: cfe-commits, AlexeySotkin
Differential Revision: https://reviews.llvm.org/D25305
llvm-svn: 285557
__builtin_alloca always uses __BIGGEST_ALIGNMENT__ for the alignment of
the allocation. __builtin_alloca_with_align allows the programmer to
specify the alignment of the allocation.
This fixes PR30658.
llvm-svn: 285544
Summary:
This patch was introduced one year ago, but because my google account
was disabled, I didn't get email with failing buildbot and I missed
revert of this commit. There was small but in test regex.
I am back.
Reviewers: rsmith, rengolin
Subscribers: nlewycky, rjmccall, cfe-commits
Differential Revision: https://reviews.llvm.org/D26117
llvm-svn: 285497
GCC documents __builtin_alloca as aligning the storage to at least
__BIGGEST_ALIGNMENT__.
MSVC documents essentially the same for the x64 ABI:
https://msdn.microsoft.com/en-us/library/x9sx5da1.aspx
The 32-bit ABI follows the same rule: it emits a call to _alloca_probe_16
Differential Revision: https://reviews.llvm.org/D24378
llvm-svn: 285316
getClassAtVTableLocation hunts through virtual bases without using the
MDC layout which is indicative of a bug.
Instead, reuse the getVFPtrOffsets machinery to calculate which
subobject within the MDC is responsible for the vfptr.
Differential Revision: https://reviews.llvm.org/D25895
llvm-svn: 285315
This is essential when clang is running in incremental processing mode because
we don't want to reemit the 'tors over and over again.
Patch by Axel Naumann!
Reviewed by Richard Smith and me. (https://reviews.llvm.org/D25605)
llvm-svn: 285277
abstract information about the callee. NFC.
The goal here is to make it easier to recognize indirect calls and
trigger additional logic in certain cases. That logic will come in
a later patch; in the meantime, I felt that this was a significant
improvement to the code.
llvm-svn: 285258
Summary:
Current generation of lifetime intrinsics does not handle cases like:
```
{
char x;
l1:
bar(&x, 1);
}
goto l1;
```
We will get code like this:
```
%x = alloca i8, align 1
call void @llvm.lifetime.start(i64 1, i8* nonnull %x)
br label %l1
l1:
%call = call i32 @bar(i8* nonnull %x, i32 1)
call void @llvm.lifetime.end(i64 1, i8* nonnull %x)
br label %l1
```
So the second time bar was called for x which is marked as dead.
Lifetime markers here are misleading so it's better to remove them at all.
This type of bypasses are rare, e.g. code detects just 8 functions building
clang (2329 targets).
PR28267
Reviewers: eugenis
Subscribers: beanz, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D24693
llvm-svn: 285176
Summary: D24693 will need access to it from other places
Reviewers: eugenis
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24695
llvm-svn: 285158
Summary:
Fixes PR28281.
MSVC lists indirect virtual base classes in the field list of a class.
This change makes Clang emit the information necessary for LLVM to
emit such records.
Reviewers: rnk, ruiu, zturner
Differential Revision: https://reviews.llvm.org/D25579
llvm-svn: 285132
This allows for the coalescing of the protocol declarations. When the protocols
are declared in headers, multiple definitions of the protocol would be emitted.
Marking them as common data indicates that any one can be selected.
llvm-svn: 285073
Move all the label construction for the various method list emission into
EmitMethodList. Rather than have all the names be constructed in pieces in all
of the callers of EmitMethodList, have this occur in one site. This also makes
the calls much easier to understand as we simplify identify the type of the
method list being emitted and the interface name for which it is being emitted.
NFC.
llvm-svn: 285023
This reverts commit r285007 and reapply r284990, with a fix for the
opencl test that I broke. Original commit message follows:
These new builtins support a mechanism for logging OS events, using a
printf-like format string to specify the layout of data in a buffer.
The _buffer_size version of the builtin can be used to determine the size
of the buffer to allocate to hold the data, and then __builtin_os_log_format
can write data into that buffer. This implements format checking to report
mismatches between the format string and the data arguments. Most of this
code was written by Chris Willmore.
Differential Revision: https://reviews.llvm.org/D25888
llvm-svn: 285019
These new builtins support a mechanism for logging OS events, using a
printf-like format string to specify the layout of data in a buffer.
The _buffer_size version of the builtin can be used to determine the size
of the buffer to allocate to hold the data, and then __builtin_os_log_format
can write data into that buffer. This implements format checking to report
mismatches between the format string and the data arguments. Most of this
code was written by Chris Willmore.
Differential Revision: https://reviews.llvm.org/D25888
llvm-svn: 284990
Summary:
SetVector already used DenseSet, but SmallSetVector used std::set. This
leads to surprising performance differences. Moreover, it means that
the set of key types accepted by SetVector and SmallSetVector are
quite different!
In order to make this change, we had to convert some callsites that used
SmallSetVector<std::string, N> to use SmallSetVector<CachedHashString, N>
instead.
Reviewers: timshen
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25648
llvm-svn: 284887
If we see a virtual method call to Base::foo() but can infer that the
object is an instance of Derived, and that 'foo' is marked 'final' in
Derived, we can devirtualize the call to Derived::foo().
Differential Revision: https://reviews.llvm.org/D25813
llvm-svn: 284766
Preparation to implement DW_AT_alignment support:
- We pass non-zero align value to DIBuilder only when alignment was forced
- Modify tests to match this change
Differential Revision: https://reviews.llvm.org/D24426
llvm-svn: 284679
LLVM now uses uint32_t for DebugInfo alignment for space efficiency,
in this patch we change frontend DebugInfo-related variables to uint32_t too.
Differential Revision: https://reviews.llvm.org/D25621
llvm-svn: 284651
ubsan reports a false positive 'invalid member call' diagnostic on the
following example (PR30478):
struct Base1 {
virtual int f1() { return 1; }
};
struct Base2 {
virtual int f1() { return 2; }
};
struct Derived2 final : Base1, Base2 {
int f1() override { return 3; }
};
int t1() {
Derived2 d;
return static_cast<Base2 *>(&d)->f1();
}
Adding the "final" attribute to a most-derived class allows clang to
devirtualize member calls into an instance of that class. We should pass
along the type info of the object pointer to avoid the FP. In this case,
that means passing along the type info for 'Derived2' instead of 'Base2'
when checking the dynamic type of static_cast<Base2 *>(&d2).
Differential Revision: https://reviews.llvm.org/D25448
llvm-svn: 284636
getClassAtVTableLocation() was calling
ASTRecordLayout::getBaseClassOffset() on a virtual base, causing an
assert.
Differential Revision: https://reviews.llvm.org/D25779
llvm-svn: 284624
constexpr variable.
When compiling a constexpr NSString initialized with an objective-c
string literal, CodeGen emits objc_storeStrong on an uninitialized
alloca, which causes a crash.
This patch folds the code in EmitScalarInit into EmitStoreThroughLValue
and fixes the crash by calling objc_retain on the string instead of
using objc_storeStrong.
rdar://problem/28562009
Differential Revision: https://reviews.llvm.org/D25547
llvm-svn: 284516
Summary: We need `__stosb` to be an intrinsic, because SecureZeroMemory function uses it without including intrin.h. Implementing it as a volatile memset is not consistent with MSDN specification, but it gives us target-independent IR while keeping the most important properties of `__stosb`.
Reviewers: rnk, hans, thakis, majnemer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25334
llvm-svn: 284253
Summary: Previously global 64-bit versions of _Interlocked functions broke buildbots on i386, so now I'm adding them as builtins for x86-64 and ARM only (should they be also on AArch64? I had problems with testing it for AArch64, so I left it)
Reviewers: hans, majnemer, mstorsjo, rnk
Subscribers: cfe-commits, aemerson
Differential Revision: https://reviews.llvm.org/D25576
llvm-svn: 284172
Summary:
Emitting deferred diagnostics during codegen was a hack. It did work,
but usability was poor, both for us as compiler devs and for users. We
don't codegen if there are any sema errors, so for users this meant that
they wouldn't see deferred errors if there were any non-deferred errors.
For devs, this meant that we had to carefully split up our tests so that
when we tested deferred errors, we didn't emit any non-deferred errors.
This change moves checking for deferred errors into Sema. See the big
comment in SemaCUDA.cpp for an overview of the idea.
This checking adds overhead to compilation, because we have to maintain
a partial call graph. As a result, this change makes deferred errors a
CUDA-only concept (whereas before they were a general concept). If
anyone else wants to use this framework for something other than CUDA,
we can generalize at that time.
This patch makes the minimal set of test changes -- after this lands,
I'll go back through and do a cleanup of the tests that we no longer
have to split up.
Reviewers: rnk
Subscribers: cfe-commits, rsmith, tra
Differential Revision: https://reviews.llvm.org/D25541
llvm-svn: 284158
Incorrect specification of the calling convention results in UB which can cause
the code path to be eliminated. Simplify the existing code by using the
RuntimeCall constructor in `CodeGenFunction`.
llvm-svn: 284154
access, by Erich Keane
OpenMP creates a variable array type with a a null size-expr. The Debug
generation failed to due to this. This patch corrects the openmp
implementation, updates the tests, and adds a new one for this
condition.
Differential Revision: https://reviews.llvm.org/D25373
llvm-svn: 284110
Summary: _BitScan intrinsics (and some others, for example _Interlocked and _bittest) are supposed to work on both ARM and x86. This is an attempt to isolate them, avoiding repeating their code or writing separate function for each builtin.
Reviewers: hans, thakis, rnk, majnemer
Subscribers: RKSimon, cfe-commits, aemerson
Differential Revision: https://reviews.llvm.org/D25264
llvm-svn: 284060
This reverts commit r283802. It introduces temporarily static
initializers, because StringRef ctor isn't (yet) constexpr for
string literals.
I plan to get there this week, but apparently GCC is so terrible
with these static initializer right now (10 min+ extra codegen
time was reported) that I'll hold on to this patch till the
constexpr one is ready, and land these at the same time.
llvm-svn: 283920
The backend now has the capability to save information from optimizations, the
same information that can be used to generate optimization diagnostics but in
machine-consumable form, into an output file. This can be enabled when using
opt (see r282539), and this change enables it when using clang. The idea is
that other tools will be able to consume these files, and perhaps in
combination with the original source code, produce various kinds of
optimization reports for users (and for compiler developers).
We now have at-least two tools that can consume these files:
* tools/llvm-opt-report
* utils/opt-viewer
Using the flag -fsave-optimization-record will cause the YAML file to be
generated; the file name will be based on the output file name (if we're using
-c or -S and have an output name), or the input file name. When we're using
CUDA, or some other offloading mechanism, separate files are generated for each
backend target. The output file name can be specified by the user using
-foptimization-record-file=filename.
Differential Revision: https://reviews.llvm.org/D25225
llvm-svn: 283834
Summary:
Move CheckCUDACall from ActOnCallExpr and BuildDeclRefExpr to
DiagnoseUseOfDecl. This lets us catch some edge cases we were missing,
specifically around class operators.
This necessitates a few other changes:
- Avoid emitting duplicate deferred diags in CheckCUDACall.
Previously we'd carefully placed our call to CheckCUDACall such that
it would only ever run once for a particular callsite. But now this
isn't the case.
- Emit deferred diagnostics from a template
specialization/instantiation's primary template, in addition to from
the specialization/instantiation itself. DiagnoseUseOfDecl ends up
putting the deferred diagnostics on the template, rather than the
specialization, so we need to check both.
Reviewers: rsmith
Subscribers: cfe-commits, tra
Differential Revision: https://reviews.llvm.org/D24573
llvm-svn: 283637
new expression, distinguish between the case of a constant and non-constant
initializer. In the former case, if the bound is erroneous (too many
initializer elements, bound is negative, or allocated size overflows), reject,
and take the bound into account when determining whether we need to
default-construct any elements. In the remanining cases, move the logic to
check for default-constructibility of trailing elements into the initialization
code rather than inventing a bogus array bound, to cope with cases where the
number of initialized elements is not the same as the number of initializer
list elements (this can happen due to string literal initialization or brace
elision).
This also fixes rejects-valid and crash-on-valid errors when initializing a
new'd array of character type from a braced string literal.
llvm-svn: 283406
Summary:
This prevents clang from emitting 'invoke's and catch statements.
Things previously mostly worked thanks to TryToMarkNoThrow() in
CodeGenFunction. But this is not a proper IPO, and it doesn't properly
handle cases like mutual recursion.
Fixes bug 30593.
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25166
llvm-svn: 283272
Summary:
This will let us (in a separate patch) allocate deferred diagnostics in
the ASTContext's PartialDiagnostic arena.
Reviewers: rnk
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25260
llvm-svn: 283271
Summary: We need x86-64-specific builtins if we want to implement some of the MS intrinsics - winnt.h contains definitions of some functions for i386, but not for x86-64 (for example _InterlockedOr64), which means that we cannot treat them as builtins for both i386 and x86-64, because then we have definitions of builtin functions in winnt.h on i386.
Reviewers: thakis, majnemer, hans, rnk
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24598
llvm-svn: 283264
The motivation for the change is that we can't have pseudo-global settings
for codegen living in TargetOptions because that doesn't work with LTO.
Ideally, these reciprocal attributes will be moved to the instruction-level
via FMF, metadata, or something else. But making them function attributes is
at least an improvement over the current state.
I'm committing this patch ahead of the related LLVM patch to avoid bot failures,
but if that patch needs to be reverted, then this should be reverted too.
Differential Revision: https://reviews.llvm.org/D24815
llvm-svn: 283251
This eliminates a class of false positives for -fsanitize=array-bounds
on instrumented ObjC projects.
Differential Revision: https://reviews.llvm.org/D22227
llvm-svn: 283249
Summary:
With this commit simple coroutines can be created in plain C using coroutine builtins.
Reviewers: rnk, EricWF, rsmith
Subscribers: modocache, mgorny, mehdi_amini, beanz, cfe-commits
Differential Revision: https://reviews.llvm.org/D24373
llvm-svn: 283155
When ARC is enabled, an ObjCIndirectCopyRestoreExpr models the passing
of a function argument s.t:
* The argument is copied into a temporary,
* The temporary is passed into the function, and
* After the function call completes, the temporary is move-assigned
back to the original location of the argument.
The argument type and the parameter type must agree "except possibly in
qualification". This commit weakens an assertion in EmitCallArg() to
actually reflect that.
llvm-svn: 283116
__builtin_astype is used to cast OpenCL opaque types to other types, as such, it needs to be able to handle casting from and to pointer types correctly.
Current it cannot handle 1) casting between pointers of different addr spaces 2) casting between pointer type and non-pointer types.
This patch fixes that.
Differential Revision: https://reviews.llvm.org/D25123
llvm-svn: 283114
Reapplying the patch after modifying the test case.
Inlining the destructor caused the compiler to generate bad IR which failed the Verifier in the backend.
https://llvm.org/bugs/show_bug.cgi?id=30341
This patch disables alias to available_externally definitions.
Reviewers: eugenis, rsmith
Differential Revision: https://reviews.llvm.org/D24682
llvm-svn: 283063
Enable soft-float support on PPC64, as the backend now supports it. Also, the
backend now uses -hard-float instead of +soft-float, so set the target features
accordingly.
Fixes PR26970.
llvm-svn: 283061
When emitting the fundamental type information constants, inherit the
DLLExportAttr from `__fundamental_type_info`. We would previously not
honor the `__declspec(dllexport)` on the type information.
llvm-svn: 282980
These are supposed to produce the same as normal volatile
pointer loads/stores. When -volatile:ms is specified,
normal volatile pointers are forced to have atomic semantics
(as is the default on x86 in MSVC mode). In that case,
these builtins should still produce non-atomic volatile
loads/stores without acquire/release semantics, which
the new test verifies.
These are only available on ARM (and on AArch64,
although clang doesn't support AArch64/Windows yet).
This implements what is missing for PR30394, making it possible
to compile C++ for ARM in MSVC mode with MSVC headers.
Differential Revision: https://reviews.llvm.org/D24986
llvm-svn: 282900
Summary:
This lets people link against LLVM and their own version of the UTF
library.
I determined this only affects llvm, clang, lld, and lldb by running
$ git grep -wl 'UTF[0-9]\+\|\bConvertUTF\bisLegalUTF\|getNumBytesFor' | cut -f 1 -d '/' | sort | uniq
clang
lld
lldb
llvm
Tested with
ninja lldb
ninja check-clang check-llvm check-lld
(ninja check-lldb doesn't complete for me with or without this patch.)
Reviewers: rnk
Subscribers: klimek, beanz, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D24996
llvm-svn: 282822
Instead of ignoring the evaluation order rule, ignore the "destroy parameters
in reverse construction order" rule for the small number of problematic cases.
This only causes incorrect behavior in the rare case where both parameters to
an overloaded operator <<, >>, ->*, &&, ||, or comma are of class type with
non-trivial destructor, and the program is depending on those parameters being
destroyed in reverse construction order.
We could do a little better here by reversing the order of parameter
destruction for those functions (and reversing the argument evaluation order
for all direct calls, not just those with operator syntax), but that is not a
complete solution to the problem, as the same situation can be reached by an
indirect function call.
Approach reviewed off-line by rnk.
llvm-svn: 282777
Inlining the destructor caused the compiler to generate bad IR which failed the Verifier in the backend.
https://llvm.org/bugs/show_bug.cgi?id=30341
This patch disables alias to available_externally definitions.
Reviewers: eugenis, rsmith
Differential Revision: https://reviews.llvm.org/D24682
llvm-svn: 282679
function correctly when targeting MS ABIs (this appears to have never mattered
prior to this change).
Update test case to always cover both 32-bit and 64-bit Windows ABIs, since
they behave somewhat differently from each other here.
Update test case to also cover operators , && and ||, which it appears are also
affected by P0145R3 (they're not explicitly called out by the design document,
but this is the emergent behavior of the existing wording).
Original commit message:
P0145R3 (C++17 evaluation order tweaks): evaluate the right-hand side of
assignment and compound-assignment operators before the left-hand side. (Even
if it's an overloaded operator.)
This completes the implementation of P0145R3 + P0400R0 for all targets except
Windows, where the evaluation order guarantees for <<, >>, and ->* are
unimplementable as the ABI requires the function arguments are evaluated from
right to left (because parameter destructors are run from left to right in the
callee).
llvm-svn: 282619
assignment and compound-assignment operators before the left-hand side. (Even
if it's an overloaded operator.)
This completes the implementation of P0145R3 + P0400R0 for all targets except
Windows, where the evaluation order guarantees for <<, >>, and ->* are
unimplementable as the ABI requires the function arguments are evaluated from
right to left (because parameter destructors are run from left to right in the
callee).
llvm-svn: 282556
This patch fixes a regression introduced in r262697 that changed the way the
coverage regions for switches are constructed. The PGO instrumentation counter
for a switch statement refers to the counter at the exit of the switch.
Therefore, the coverage region for the switch statement should cover the code
that comes after the switch, and not the switch statement itself.
rdar://28480997
Differential Revision: https://reviews.llvm.org/D24981
llvm-svn: 282554
This patch corresponds to review:
https://reviews.llvm.org/D24397
It adds the __POWER9_VECTOR__ macro and the -mpower9-vector option along with
a number of altivec.h functions (refer to the code review for a list).
llvm-svn: 282481
__attribute__((amdgpu_flat_work_group_size(<min>, <max>))) - request minimum and maximum flat work group size
__attribute__((amdgpu_waves_per_eu(<min>[, <max>]))) - request minimum and/or maximum waves per execution unit
Differential Revision: https://reviews.llvm.org/D24513
llvm-svn: 282371
Use the new CreateCStringLiteral in an additional site. Now all the C string
literals are created in one function. Furthermore, mark the additional literal
as an `unnamed_addr constant`.
llvm-svn: 281997
Summary: We previously relies on InstructionCombining pass to remove invoke instructions. Now that we can inline invoke instructions correctly, we do not need these passes any more.
Reviewers: dnovillo
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D24730
llvm-svn: 281910
These are all emitted into a section with a cstring_literal attribute. The
attribute permits the linker to coalesce the string contents. The address of
the strings are not important.
llvm-svn: 281855
These strings are constants, mark them as such. This doesn't matter too much in
practice on MachO since the constants are placed into a special section and not
referred to directly.
llvm-svn: 281854
This refactors the cstring literal creation as mentioned in the couple of FIXMEs
littered in the various invocations to CreateMetadataVar. This centralises the
definition of the literals, and will enable changing the literal creation to a
single site. NFC.
llvm-svn: 281798
* recurse through intermediate LabelStmts and AttributedStmts when checking
whether a statement inside a switch declares a variable
* if the end of a compound statement is reachable from the chosen case label,
and the compound statement contains a variable declaration, it's not valid
to just emit the contents of the compound statement -- we must emit the
statement itself or we lose the scope (and thus end lifetimes at the wrong
point)
llvm-svn: 281797
Address post-commit comments from Justin Bogner. Explicitly indicate
that the dereferenced iterator provides a pointer rather than a
reference. NFC.
llvm-svn: 281730
virtual table offset in a member function pointer.
We are reserving this space for future ABI use relating to alternative
v-table configurations. In the meantime, continue to zero-initialize
this space when actually emitting a member pointer literal.
This will successfully interoperate with existing compilers.
Future versions of the compiler may place additional data in
this location, and at that point, code emitted by compilers
prior to this patch will fail if exposed to such a member pointer.
This is therefore a somewhat hard ABI break. However, because
it is limited to an uncommon case of an uncommon language feature,
and especially because interoperation with the standard library
does not depend on member pointers, we believe that with a
sufficiently advance compiler change the impact of this break
will be minimal in practice.
llvm-svn: 281693
field in the enclosing lambda or block.
This patch fixes a bug in code-gen where it uses the type of the
declared variable rather than the type of the capture of the enclosing
lambda or block for the block capture. For example, in the following
function, code-gen currently uses i32* for the block capture "a" because
"a" is passed to foo1 as a reference, but it should use i32 since the
enclosing lambda captures "a" by value.
void foo1(int &a) {
auto lambda = [a]{
auto block1 = ^{
i = a;
};
block1();
};
lambda();
}
rdar://problem/18586386
Differential Revision: https://reviews.llvm.org/D21104
llvm-svn: 281682
Summary: This patch converts finite/__finite to builtin functions so that it will be inlined by compiler.
Reviewers: hfinkel, davidxl, efriedma
Subscribers: efriedma, llvm-commits
Differential Revision: https://reviews.llvm.org/D24483
llvm-svn: 281509
Move the definition of `getTriple()` into the header. It would just call
`getTarget().getTriple()`. Inline the definition to allow the compiler to see
the same amount of the layout as previously. Remove the more verbose
`getTarget().getTriple()` in favour of `getTriple()`.
llvm-svn: 281487
Chandler Carruth