| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
In r253186, I changed the DIBuilder API to now take size and align
for reference types as well. This was done in preparation for upcoming
changes to the Verifier that will validate that sizes match between
DI types and IR values that are declared as having those types.
This updates clang to actually pass the information through.
llvm-svn: 253190
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
beyond value/repair
Several of these tests (the two deleted, and the one removal edit) were
relying on the optimizer to collapse things to test some frontend
feature. The tests were really old and features seemed amply covered by
other parts of the test suite, so I just removed them.
If anyone thinks they're valuable enough to keep/fix, we can play around
with that, for sure.
(inspired by r252872)
llvm-svn: 253114
|
|
|
|
|
|
|
|
| |
It has been reported that this test currently fails on some Power buildbots due to them adding a "signext" function attribute.
As that's not what we're checking here, slacken off the test a bit.
llvm-svn: 253055
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ``disable_tail_calls`` attribute instructs the backend to not
perform tail call optimization inside the marked function.
For example,
int callee(int);
int foo(int a) __attribute__((disable_tail_calls)) {
return callee(a); // This call is not tail-call optimized.
}
Note that this attribute is different from 'not_tail_called', which
prevents tail-call optimization to the marked function.
rdar://problem/8973573
Differential Revision: http://reviews.llvm.org/D12547
llvm-svn: 252986
|
|
|
|
|
|
| |
The C++ spec (3.6.1.3) says "The function `main` shall not be used within a program". This implies that it cannot recurse, so add the norecurse attribute to help the midend out a bit.
llvm-svn: 252902
|
|
|
|
|
|
| |
FunctionAttrs has just been taught how to infer 'norecurse'. Update clang tests for LLVM r252871.
llvm-svn: 252872
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is about how we handle static member of a template. Before this commit,
we use internal linkage for the IR thread-local variable, which is inefficient.
With this commit, we will start to follow Itanium C++ ABI.
rdar://problem/23415206
Reviewed by John McCall.
llvm-svn: 252814
|
|
|
|
|
|
|
|
| |
We used to emit the store prior to branch in the entry block. To make it more
efficient, this commit moves it to the init block. We still mark as initialized
before initializing anything else.
llvm-svn: 252777
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This comes up when a derived class destructor is equivalent to a base
class destructor defined in the same TU, and we try to alias them.
A COFF weak alias cannot satisfy a normal undefined symbol reference
from another TU. The other TU must also mark the referenced symbol as
weak, and we can't rely on that.
Clang already has a special case here for dllexport, but we failed to
realize that the problem also applies to other non-discardable symbols
such as those from explicit template instantiations.
Fixes PR25477.
llvm-svn: 252659
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The attrubite is applicable to functions and variables and changes
the linkage of the subject to internal.
This is the same functionality as C-style "static", but applicable to
class methods; and the same as anonymouns namespaces, but can apply
to individual methods of a class.
Following the proposal in
http://lists.llvm.org/pipermail/cfe-dev/2015-October/045580.html
llvm-svn: 252648
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This attribute is used to prevent tail-call optimizations to the marked
function. For example, in the following piece of code, foo1 will not be
tail-call optimized:
int __attribute__((not_tail_called)) foo1(int);
int foo2(int a) {
return foo1(a); // Tail-call optimization is not performed.
}
The attribute has effect only on statically bound calls. It has no
effect on indirect calls. Also, virtual functions and objective-c
methods cannot be marked as 'not_tail_called'.
rdar://problem/22667622
Differential Revision: http://reviews.llvm.org/D12922
llvm-svn: 252369
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14266
llvm-svn: 252220
|
|
|
|
|
|
|
|
|
|
|
|
| |
Certain CXXConstructExpr nodes require zero-initialization before a
constructor is called. We had a bug in the case where the constructor
is called on a virtual base: we zero-initialized the base's vbptr field.
A complementary bug is present in MSVC where no zero-initialization
occurs for the subobject at all.
This fixes PR25370.
llvm-svn: 251783
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
attributes to internal functions.
This patch fixes CodeGenModule::CreateGlobalInitOrDestructFunction to
use SetInternalFunctionAttributes instead of SetLLVMFunctionAttributes
to attach function attributes to internal functions.
Also, make sure the correct CGFunctionInfo is passed instead of always
passing what arrangeNullaryFunction returns.
rdar://problem/20828324
Differential Revision: http://reviews.llvm.org/D13610
llvm-svn: 251734
|
|
|
|
| |
llvm-svn: 251710
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This works around PR25162. The MSVC tables make it very difficult to
correctly inline a C++ destructor that contains try / catch. We've
attempted to address PR25162 in LLVM's backend, but it feels pretty
infeasible. MSVC and ICC both appear to avoid inlining such complex
destructors.
Long term, we want to fix this by making the inliner smart enough to
know when it is inlining into a cleanup, so it can inline simple
destructors (~unique_ptr and ~vector) while avoiding destructors
containing try / catch.
llvm-svn: 251576
|
|
|
|
|
|
|
|
|
|
|
|
| |
We believed that internal linkage variables at global scope which are
not variable template specializations did not have to be mangled.
However, static anonymous unions have no identifier and therefore must
be mangled.
This fixes PR18204.
llvm-svn: 250997
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ELF symbol visibilities are:
- internal: Not visibile across DSOs, cannot pass address across DSOs
- hidden: Not visibile across DSOs, can be called indirectly
- default: Usually visible across DSOs, possibly interposable
- protected: Visible across DSOs, not interposable
LLVM only supports the latter 3 visibilities. Internal visibility is in
theory useful, as it allows you to assume that the caller is maintaining
a PIC register for you in %ebx, or in some other pre-arranged location.
As far as LLVM is concerned, this isn't worth the trouble. Using hidden
visibility is always correct, so we can just do that.
Resolves PR9183.
llvm-svn: 250954
|
|
|
|
|
|
|
| |
Currently debug info for types used in explicit cast only is not emitted. It happened after a patch for better alignment handling. This patch fixes this bug.
Differential Revision: http://reviews.llvm.org/D13582
llvm-svn: 250795
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
static data members
Out-of-line definitions of static data members which have an inline
initializer must get GVA_DiscardableODR linkage instead of
GVA_StrongExternal linkage.
MSVC 2013's behavior is different with respect to this and would cause
link errors if one TU provided a definition while another did not.
MSVC 2015 fixed this bug, making this OK. Note that the 2015 behavior
is always compatible with 2013: it never produces a strong definition.
This essentially reverts r237787.
llvm-svn: 250757
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, our logic when taking the address of an overloaded function
would not consider enable_if attributes, so long as all of the enable_if
conditions on a given candidate were true. So, two functions with
identical signatures (one with enable_if attributes, the other without),
would be considered equally good overloads. If we were calling the
function instead of taking its address, then the function with enable_if
attributes would be preferred.
This patch makes us prefer the candidate with enable_if regardless of if
we're calling or taking the address of an overloaded function.
Differential Revision: http://reviews.llvm.org/D13795
llvm-svn: 250486
|
|
|
|
|
|
|
|
|
| |
invocations of foo() when compiling foo()->propertyName
Removes extra codegen for base expression of MS property call
Differential Revision: http://reviews.llvm.org/D13375
llvm-svn: 250265
|
|
|
|
|
|
|
| |
We were only doing this for SEH as a special case. Generalize it to all
cleanups.
llvm-svn: 249748
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
-fms-compatibility
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
|
|
|
|
|
|
|
| |
Testing has shown that it is at least as reliable as the old landingpad
pattern matching code.
llvm-svn: 249647
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
something. :)
llvm-svn: 249223
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 248984
|
|
|
|
|
|
| |
http://reviews.llvm.org/D13279
llvm-svn: 248982
|
|
|
|
|
|
| |
with a non-reserved operator delete in a new-expression.
llvm-svn: 248862
|
|
|
|
|
|
|
| |
Temporary fix till InstCombine and other possible passes will be
efficient to handle multiple assumes.
llvm-svn: 248734
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Seems it would be redundant.
llvm-svn: 247761
|
|
|
|
| |
llvm-svn: 247743
|
|
|
|
| |
llvm-svn: 247742
|
|
|
|
| |
llvm-svn: 247733
|
|
|
|
|
|
|
|
|
|
| |
Adding !invariant.group to vptr load/stores for devirtualization purposes.
For more goto:
http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html
http://reviews.llvm.org/D12026
llvm-svn: 247725
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
For more goto:
http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html
http://reviews.llvm.org/D12312
llvm-svn: 247723
|
|
|
|
| |
llvm-svn: 247712
|
|
|
|
|
|
|
|
| |
"opt -instnamer".
It reverts r231717.
llvm-svn: 247667
|