This reverts commit r337627.
After the change, clang started producing invalid warning on the following code:
struct foo {
foo(char *x) : x_(&x[10]) {}
private:
char *x_;
};
1.cpp:2:21: warning: initializing pointer member 'x_' with the stack address of parameter 'x' [-Wdangling-field]
llvm-svn: 337671
MSVC doesn't, so neither should we.
Fixes PR38004, which is a crash that happens when we try to emit debug
info for a still-dependent partial variable template specialization.
As a follow-up, we should review what we're doing for function and class
member templates. It looks like we don't filter those out, but I can't
seem to get clang to emit any.
llvm-svn: 337616
Currently clang does not allow implicit cast of a pointer to a pointer type
in different address space but allows C-style cast of a pointer to a pointer
type in different address space. However, there is a bug in Sema causing
incorrect Cast Expr in AST for the latter case, which in turn results in
invalid LLVM IR in codegen.
This is because Sema::IsQualificationConversion returns true for a cast of
pointer to a pointer type in different address space, which in turn allows
a standard conversion and results in a cast expression with no op in AST.
This patch fixes that by let Sema::IsQualificationConversion returns false
for a cast of pointer to a pointer type in different address space, which
in turn disallows standard conversion, implicit cast, and static cast.
Finally it results in an reinterpret cast and correct conversion kind is set.
Differential Revision: https://reviews.llvm.org/D49294
llvm-svn: 337540
The previous version of this patch (r332839) was reverted because it was
causing "definition with same mangled name as another definition" errors
in some module builds. This was caused by an unrelated bug in module
importing which it exposed. The importing problem was fixed in r336240,
so this recommits the original patch (r332839).
Differential Revision: https://reviews.llvm.org/D46685
llvm-svn: 337456
Summary:
Support for this option is needed for building Linux kernel.
This is a very frequently requested feature by kernel developers.
More details : https://lkml.org/lkml/2018/4/4/601
GCC option description for -fdelete-null-pointer-checks:
This Assume that programs cannot safely dereference null pointers,
and that no code or data element resides at address zero.
-fno-delete-null-pointer-checks is the inverse of this implying that
null pointer dereferencing is not undefined.
This feature is implemented in as the function attribute
"null-pointer-is-valid"="true".
This CL only adds the attribute on the function.
It also strips "nonnull" attributes from function arguments but
keeps the related warnings unchanged.
Corresponding LLVM change rL336613 already updated the
optimizations to not treat null pointer dereferencing
as undefined if the attribute is present.
Reviewers: t.p.northover, efriedma, jyknight, chandlerc, rnk, srhines, void, george.burgess.iv
Reviewed By: jyknight
Subscribers: drinkcat, xbolva00, cfe-commits
Differential Revision: https://reviews.llvm.org/D47894
llvm-svn: 337433
This patch uses CodeSegAttr to represent __declspec(code_seg) rather than
building on the existing support for #pragma code_seg.
The code_seg declspec is applied on functions and classes. This attribute
enables the placement of code into separate named segments, including compiler-
generated codes and template instantiations.
For more information, please see the following:
https://msdn.microsoft.com/en-us/library/dn636922.aspx
This patch fixes the regression for the support for attribute ((section).
746b78de78
Patch by Soumi Manna (Manna)
Differential Revision: https://reviews.llvm.org/D48841
llvm-svn: 337420
This change implements C++ DR1696, which makes initialization of a
reference member of a class from a temporary object ill-formed. The
standard wording here is imprecise, but we interpret it as meaning that
any time a mem-initializer would result in lifetime extension, the
program is ill-formed.
This reinstates r337226, reverted in r337255, with a fix for the
InitializedEntity alignment problem that was breaking ARM buildbots.
llvm-svn: 337329
This change breaks on ARM because pointers to clang::InitializedEntity are only
4 byte aligned and do not have 3 bits to store values. A possible solution
would be to change the fields in clang::InitializedEntity to enforce a bigger
alignment requirement.
The error message is
llvm/include/llvm/ADT/PointerIntPair.h:132:3: error: static_assert failed "PointerIntPair with integer size too large for pointer"
static_assert(IntBits <= PtrTraits::NumLowBitsAvailable,
include/llvm/ADT/PointerIntPair.h:73:13: note: in instantiation of template class 'llvm::PointerIntPairInfo<const clang::InitializedEntity *, 3, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *> >' requested here
Value = Info::updateInt(Info::updatePointer(0, PtrVal),
llvm/include/llvm/ADT/PointerIntPair.h:51:5: note: in instantiation of member function 'llvm::PointerIntPair<const clang::InitializedEntity *, 3, (anonymous namespace)::LifetimeKind, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *>, llvm::PointerIntPairInfo<const clang::InitializedEntity *, 3, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *> > >::setPointerAndInt' requested here
setPointerAndInt(PtrVal, IntVal);
^
llvm/tools/clang/lib/Sema/SemaInit.cpp:6237:12: note: in instantiation of member function 'llvm::PointerIntPair<const clang::InitializedEntity *, 3, (anonymous namespace)::LifetimeKind, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *>, llvm::PointerIntPairInfo<const clang::InitializedEntity *, 3, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *> > >::PointerIntPair' requested here
return {Entity, LK_Extended};
Full log here:
http://lab.llvm.org:8011/builders/clang-cmake-armv7-global-isel/builds/1330http://lab.llvm.org:8011/builders/clang-cmake-armv7-full/builds/1394
llvm-svn: 337255
This change implements C++ DR1696, which makes initialization of a
reference member of a class from a temporary object ill-formed. The
standard wording here is imprecise, but we interpret it as meaning that
any time a mem-initializer would result in lifetime extension, the
program is ill-formed.
llvm-svn: 337226
This mangles entry points wmain, WinMain, wWinMain or DllMain as C
functions, to match the ABI for these functions.
We already did the same for these functions in MSVC mode, but we also
should do the same in the Itanium ABI.
This fixes PR38124.
Differential Revision: https://reviews.llvm.org/D49354
llvm-svn: 337146
As brought up on cfe-commits[1], r334650 causes the dependency of the
out parameter to the __builtin_*_overflow functions to be ignored. The result
was a usage that was otherwise constexpr (both operands to the operation were
constexpr) would be evaluated, but the out parameter wouldn't be modified, so
it would still be 'undef'.
This patch correctly handles the return value of handleAssignment to ensure that
this value is properly considered/evaluated.
[1] http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180702/233667.html
llvm-svn: 336364
Summary:
Emmiting new intrinsic that strips invariant.groups to make
devirtulization sound, as described in RFC: Devirtualization v2.
Reviewers: rjmccall, rsmith, amharc, kuhar
Subscribers: llvm-commits, cfe-commits
Differential Revision: https://reviews.llvm.org/D47299
Co-authored-by: Krzysztof Pszeniczny <krzysztof.pszeniczny@gmail.com>
llvm-svn: 336137
MSVC limits char16_t and char32_t string literal names to 32 bytes of character
data, not to 32 characters. wchar_t string literal names on the other hand can
get up to 64 bytes of character data.
https://reviews.llvm.org/D48781
llvm-svn: 336097
Similarly to CFI on virtual and indirect calls, this implementation
tries to use program type information to make the checks as precise
as possible. The basic way that it works is as follows, where `C`
is the name of the class being defined or the target of a call and
the function type is assumed to be `void()`.
For virtual calls:
- Attach type metadata to the addresses of function pointers in vtables
(not the functions themselves) of type `void (B::*)()` for each `B`
that is a recursive dynamic base class of `C`, including `C` itself.
This type metadata has an annotation that the type is for virtual
calls (to distinguish it from the non-virtual case).
- At the call site, check that the computed address of the function
pointer in the vtable has type `void (C::*)()`.
For non-virtual calls:
- Attach type metadata to each non-virtual member function whose address
can be taken with a member function pointer. The type of a function
in class `C` of type `void()` is each of the types `void (B::*)()`
where `B` is a most-base class of `C`. A most-base class of `C`
is defined as a recursive base class of `C`, including `C` itself,
that does not have any bases.
- At the call site, check that the function pointer has one of the types
`void (B::*)()` where `B` is a most-base class of `C`.
Differential Revision: https://reviews.llvm.org/D47567
llvm-svn: 335569
The recommit ensures that the tests that failed on bots don't trigger the warning.
Xcode 10 removes support for libstdc++, but the users just get a confusing
include not file warning when including an STL header (when building for iOS6
which uses libstdc++ by default for example).
This patch adds a new warning that lets the user know that the libstdc++ include
path was not found to ensure that the user is more aware of why the error occurs.
rdar://40830462
Differential Revision: https://reviews.llvm.org/D48297
llvm-svn: 335081
Summary:
This is the second attempt of r333500 (Update NRVO logic to support early return).
The previous one was reverted for a miscompilation for an incorrect NRVO set up on templates such as:
```
struct Foo {};
template <typename T>
T bar() {
T t;
if (false)
return T();
return t;
}
```
Where, `t` is marked as non-NRVO variable before its instantiation. However, while its instantiation, it's left an NRVO candidate, turned into an NRVO variable later.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D47586
llvm-svn: 335019
This is not only semantically correct but ensures that they will not
be marked as address-significant once D48155 lands.
Differential Revision: https://reviews.llvm.org/D48206
llvm-svn: 334982
Summary:
In many cases we can't devirtualize
because definition of vtable is not present. Most of the
time it is caused by inline virtual function not beeing
emitted. Forcing emitting of vtable adds a reference of these
inline virtual functions.
Note that GCC was always doing it.
Reviewers: rjmccall, rsmith, amharc, kuhar
Subscribers: llvm-commits, cfe-commits
Differential Revision: https://reviews.llvm.org/D47108
Co-authored-by: Krzysztof Pszeniczny <krzysztof.pszeniczny@gmail.com>
llvm-svn: 334600
The windows-msvc target is used for MSVC ABI compatibility, including
the exceptions model. It doesn't make sense to pair a windows-msvc
target with a non-MSVC exception model. This would previously cause an
assertion failure; explicitly error out for it in the frontend instead.
This also allows us to reduce the matrix of target/exception models a
bit (see the modified tests), and we can possibly simplify some of the
personality code in a follow-up.
Differential Revision: https://reviews.llvm.org/D47853
llvm-svn: 334243
Adding __attribute__((aligned(32))) to __m256 breaks the implementation
of _mm256_loadu_ps on Windows. On Windows, alignment attributes have
higher precedence than packing attributes.
We also might want to carefully consider the consequences of changing
our vector typedefs, since many users copy them and invent their own
new, non-Intel specific vector type names.
llvm-svn: 333958
This fixes two major problems:
- We were not capping vector alignment as desired on 32-bit ARM.
- We were using different alignments based on the AVX settings on
Intel, so we did not have a consistent ABI.
This is an ABI break, but we think we can get away with it because
vectors tend to be used mostly in inline code (which is why not having
a consistent ABI has not proven disastrous on Intel).
Intel's AVX types are specified as having 32-byte / 64-byte alignment,
so align them explicitly instead of relying on the base ABI rule.
Note that this sort of attribute is stripped from template arguments
in template substitution, so there's a possibility that code templated
over vectors will produce inadequately-aligned objects. The right
long-term solution for this is for alignment attributes to be
interpreted as true qualifiers and thus preserved in the canonical type.
llvm-svn: 333791
Summary:
clang's current wasm EH implementation is a non-MVP feature in progress.
We had a `-mexception-handling` wasm feature but were not using it. This
patch hides the non-MVP wasm EH behind a flag, so it does not affect
other code for now.
Reviewers: dschuff
Subscribers: sbc100, jgravelle-google, sunfish, cfe-commits
Differential Revision: https://reviews.llvm.org/D47614
llvm-svn: 333716
Summary:
Because wasm control flow needs to be structured, using WinEH
instructions to support wasm EH brings several benefits. This patch
makes wasm EH uses Windows EH instructions, with some changes:
1. Because wasm uses a single catch block to catch all C++ exceptions,
this merges all catch clauses into a single catchpad, within which we
test the EH selector as in Itanium EH.
2. Generates a call to `__clang_call_terminate` in case a cleanup
throws. Wasm does not have a runtime to handle this.
3. In case there is no catch-all clause, inserts a call to
`__cxa_rethrow` at the end of a catchpad in order to unwind to an
enclosing EH scope.
Reviewers: majnemer, dschuff
Subscribers: jfb, sbc100, jgravelle-google, sunfish, cfe-commits
Differential Revision: https://reviews.llvm.org/D44931
llvm-svn: 333703
Ensure latest MPT decl has a MSInheritanceAttr when instantiating
templates, to avoid null MSInheritanceAttr deref in
CXXRecordDecl::getMSInheritanceModel().
See PR#37399 for repo / details.
Patch by Andrew Rogers!
Differential Revision: https://reviews.llvm.org/D46664
llvm-svn: 333680
Summary:
The previous implementation misses an opportunity to apply NRVO (Named Return Value
Optimization) below. That discourages user to write early return code.
```
struct Foo {};
Foo f(bool b) {
if (b)
return Foo();
Foo oo;
return oo;
}
```
That is, we can/should apply RVO for a local variable if:
* It's directly returned by at least one return statement.
* And, all reachable return statements in its scope returns the variable directly.
While, the previous implementation disables the RVO in a scope if there are multiple return
statements that refers different variables.
On the new algorithm, local variables are in NRVO_Candidate state at first, and a return
statement changes it to NRVO_Disabled for all visible variables but the return statement refers.
Then, at the end of the function AST traversal, NRVO is enabled for variables in NRVO_Candidate
state and refers from at least one return statement.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: xbolva00, Quuxplusone, arthur.j.odwyer, cfe-commits
Differential Revision: https://reviews.llvm.org/D47067
llvm-svn: 333500
This helps especially when the collision is for a template specialization,
where the template arguments are not available from anywhere else in the
diagnostic, and are likely relevant to the problem.
llvm-svn: 333489
initialization functions to 'cxx_fast_tlscc'.
This fixes a bug where instructions calling initialization functions for
thread-local static members of c++ template classes were using calling
convention 'cxx_fast_tlscc' while the called functions weren't annotated
with the calling convention.
rdar://problem/40447463
Differential Revision: https://reviews.llvm.org/D47354
llvm-svn: 333447
It caused asserts, see PR37560.
> Use zeroinitializer for (trailing zero portion of) large array initializers
> more reliably.
>
> Clang has two different ways it emits array constants (from InitListExprs and
> from APValues), and both had some ability to emit zeroinitializer, but neither
> was able to catch all cases where we could use zeroinitializer reliably. In
> particular, emitting from an APValue would fail to notice if all the explicit
> array elements happened to be zero. In addition, for large arrays where only an
> initial portion has an explicit initializer, we would emit the complete
> initializer (which could be huge) rather than emitting only the non-zero
> portion. With this change, when the element would have a suffix of more than 8
> zero elements, we emit the array constant as a packed struct of its initial
> portion followed by a zeroinitializer constant for the trailing zero portion.
>
> In passing, I found a bug where SemaInit would sometimes walk the entire array
> when checking an initializer that only covers the first few elements; that's
> fixed here to unblock testing of the rest.
>
> Differential Revision: https://reviews.llvm.org/D47166
llvm-svn: 333067
more reliably.
Clang has two different ways it emits array constants (from InitListExprs and
from APValues), and both had some ability to emit zeroinitializer, but neither
was able to catch all cases where we could use zeroinitializer reliably. In
particular, emitting from an APValue would fail to notice if all the explicit
array elements happened to be zero. In addition, for large arrays where only an
initial portion has an explicit initializer, we would emit the complete
initializer (which could be huge) rather than emitting only the non-zero
portion. With this change, when the element would have a suffix of more than 8
zero elements, we emit the array constant as a packed struct of its initial
portion followed by a zeroinitializer constant for the trailing zero portion.
In passing, I found a bug where SemaInit would sometimes walk the entire array
when checking an initializer that only covers the first few elements; that's
fixed here to unblock testing of the rest.
Differential Revision: https://reviews.llvm.org/D47166
llvm-svn: 333044
Introduced CreateMemTempWithoutCast and CreateTemporaryAllocaWithoutCast to emit alloca
without casting to default addr space.
ActiveFlag is a temporary variable emitted for clean up. It is defined as AllocaInst* type and there is
a cast to AlllocaInst in SetActiveFlag. An alloca casted to generic pointer causes assertion in
SetActiveFlag.
Since there is only load/store of ActiveFlag, it is safe to use the original alloca, therefore use
CreateMemTempWithoutCast is called.
Differential Revision: https://reviews.llvm.org/D47099
llvm-svn: 332982
This change will help Visual Studio resolve forward references to C++ lambda
routines used by captured variables.
Differential Revision: https://reviews.llvm.org/D45438
llvm-svn: 332975
If a variable has an initializer, codegen tries to build its value. If
the variable is large in size, building its value requires substantial
resources. It causes strange behavior from user viewpoint: compilation
of huge zero initialized arrays like:
char data_1[2147483648u] = { 0 };
consumes enormous amount of time and memory.
With this change codegen tries to determine if variable initializer is
equivalent to zero initializer. In this case variable value is not
constructed.
This change fixes PR18978.
Differential Revision: https://reviews.llvm.org/D46241
llvm-svn: 332847
The first version of the patch (r332228) was flawed because it was
putting structors into C5/D5 comdats very eagerly. This is correct only
if we can ensure the comdat contains all required versions of the
structor (which wasn't the case). This version uses a more nuanced
approach:
- for local structor symbols we use an alias because we don't have to
worry about comdats or other compilation units.
- linkonce symbols are emitted separately, as we cannot guarantee we
will have all symbols we need to form a comdat (they are emitted
lazily, only when referenced).
- available_externally symbols are also emitted separately, as the code
seemed to be worried about emitting an alias in this case.
- other linkage types are not affected by the optimization level. They
either get put into a comdat (weak) or get aliased (external).
Reviewers: rjmccall, aprantl
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D46685
llvm-svn: 332839
When a lambda capture captures a __block in the same statement, the compiler asserts out because isCapturedBy assumes that an Expr can only be a BlockExpr, StmtExpr, or if it's a Stmt then all the statement's children are expressions. That's wrong, we need to visit all sub-statements even if they're not expressions to see if they also capture.
Fix this issue by pulling out the isCapturedBy logic to use RecursiveASTVisitor.
<rdar://problem/39926584>
llvm-svn: 332801
lifetime.start/end expects pointer argument in alloca address space.
However in C++ a temporary variable is in default address space.
This patch changes API CreateMemTemp and CreateTempAlloca to
get the original alloca instruction and pass it lifetime.start/end.
It only affects targets with non-zero alloca address space.
Differential Revision: https://reviews.llvm.org/D45900
llvm-svn: 332593
Some targets have constant address space (e.g. amdgcn). For them string literal should be
emitted in constant address space then casted to default address space.
Differential Revision: https://reviews.llvm.org/D46643
llvm-svn: 332279
Summary:
Removing the full structor and replacing all usages with the base one
can degrade debug quality as it will leave the debugger unable to locate
the full object structor. This is apparent when evaluating an expression
in the debugger which requires constructing an object of class which has
had this optimization applied to it. When compiling the expression, we
pretend that the class and its methods have been defined in another
compilation unit, so the expression compiler assumes the structor
definition must be available. This didn't use to be the case for
structors with internal linkage. Less aggressive optimizations like
emitting the full structor as an alias remain in place, as they do not
cause the structor symbol to disappear completely.
This improves debug quality on non-darwin platforms (darwin does not
have -mconstructor-aliases on by default, so it is spared these
problems) and enable us to remove some workarounds from LLDB which attempt to
mitigate this issue.
Reviewers: rjmccall, aprantl
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D46685
llvm-svn: 332228
The PS4 requires clang ABI version 6 for compatibility reasons. This change forces this and if the user specifies a different version when the PS4 target is specified, the compiler emits a warning that the specified version is being ignored.
Reviewers: probinson
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D46767
llvm-svn: 332160
Summary:
The Itanium ABI requires that the type info for pointer-to-incomplete types to have internal linkage, so that it doesn't interfere with the type info once completed. Currently it also marks the type info name as internal as well. However, this causes a bug with the STL implementations, which use the type info name pointer to perform ordering and hashing of type infos.
For example:
```
// header.h
struct T;
extern std::type_info const& Info;
// tu_one.cpp
#include "header.h"
std::type_info const& Info = typeid(T*);
// tu_two.cpp
#include "header.h"
struct T {};
int main() {
auto &TI1 = Info;
auto &TI2 = typeid(T*);
assert(TI1 == TI2); // Fails
assert(TI1.hash_code() == TI2.hash_code()); // Fails
}
```
This patch fixes the STL bug by emitting the type info name as linkonce_odr when the type-info is for a pointer-to-incomplete type.
Note that libc++ could fix this without a compiler change, but the quality of fix would be poor. The library would either have to:
(A) Always perform strcmp/string hashes.
(B) Determine if we have a pointer-to-incomplete type, and only do strcmp then. This would require an ABI break for libc++.
Reviewers: rsmith, rjmccall, majnemer, vsapsai
Reviewed By: rjmccall
Subscribers: smeenai, cfe-commits
Differential Revision: https://reviews.llvm.org/D46665
llvm-svn: 332028
Summary:
The Itanium ABI requires that the type info for pointer-to-incomplete types to have internal linkage, so that it doesn't interfere with the type info once completed. Currently it also marks the type info name as internal as well. However, this causes a bug with the STL implementations, which use the type info name pointer to perform ordering and hashing of type infos.
For example:
```
// header.h
struct T;
extern std::type_info const& Info;
// tu_one.cpp
#include "header.h"
std::type_info const& Info = typeid(T*);
// tu_two.cpp
#include "header.h"
struct T {};
int main() {
auto &TI1 = Info;
auto &TI2 = typeid(T*);
assert(TI1 == TI2); // Fails
assert(TI1.hash_code() == TI2.hash_code()); // Fails
}
```
This patch fixes the STL bug by emitting the type info name as linkonce_odr when the type-info is for a pointer-to-incomplete type.
Note that libc++ could fix this without a compiler change, but the quality of fix would be poor. The library would either have to:
(A) Always perform strcmp/string hashes.
(B) Determine if we have a pointer-to-incomplete type, and only do strcmp then. This would require an ABI break for libc++.
Reviewers: rsmith, rjmccall, majnemer, vsapsai
Reviewed By: rjmccall
Subscribers: smeenai, cfe-commits
Differential Revision: https://reviews.llvm.org/D46665
llvm-svn: 331957
Summary:
This patch tackles long hanging fruit for the builtin operator<=> expressions. It is currently needs some cleanup before landing, but I want to get some initial feedback.
The main changes are:
* Lookup, build, and store the required standard library types and expressions in `ASTContext`. By storing them in ASTContext we don't need to store (and duplicate) the required expressions in the BinaryOperator AST nodes.
* Implement [expr.spaceship] checking, including diagnosing narrowing conversions.
* Implement `ExprConstant` for builtin spaceship operators.
* Implement builitin operator<=> support in `CodeGenAgg`. Initially I emitted the required comparisons using `ScalarExprEmitter::VisitBinaryOperator`, but this caused the operand expressions to be emitted once for every required cmp.
* Implement [builtin.over] with modifications to support the intent of P0946R0. See the note on `BuiltinOperatorOverloadBuilder::addThreeWayArithmeticOverloads` for more information about the workaround.
Reviewers: rsmith, aaron.ballman, majnemer, rnk, compnerd, rjmccall
Reviewed By: rjmccall
Subscribers: rjmccall, rsmith, aaron.ballman, junbuml, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D45476
llvm-svn: 331677
the build bots to healthy again without a full revert. As the
functionality added has nothing to do with linkage this seems unlikely
to represent a deep or interesting bug in the patch.
llvm-svn: 331245
This is not yet part of any C++ working draft, and so is controlled by the flag
-fchar8_t rather than a -std= flag. (The GCC implementation is controlled by a
flag with the same name.)
This implementation is experimental, and will be removed or revised
substantially to match the proposal as it makes its way through the C++
committee.
llvm-svn: 331244
Clang incorrectly applied the packed attribute to base classes. Per GCC's
documentation and as can be observed from its behavior, packed only applies to
members, not base classes.
This change is conditioned behind -fclang-abi-compat so that an ABI break can
be avoided by users if desired.
Differential Revision: https://reviews.llvm.org/D46218
llvm-svn: 331136
We still support the old mangling if we're trying to be ABI-compatible with
Clang 6.0, though.
Differential revision: https://reviews.llvm.org/D45451
llvm-svn: 331098
function if a function delegates to another function.
Fix a bug introduced in r328731, which caused a struct with ObjC __weak
fields that was passed to a function to be destructed twice, once in the
callee function and once in another function the callee function
delegates to. To prevent this, keep track of the callee-destructed
structs passed to a function and disable their cleanups at the point of
the call to the delegated function.
This reapplies r331016, which was reverted in r331019 because it caused
an assertion to fail in EmitDelegateCallArg on a windows bot. I made
changes to EmitDelegateCallArg so that it doesn't try to deactivate
cleanups for structs that have trivial destructors (cleanups for those
structs are never pushed to the cleanup stack in EmitParmDecl).
rdar://problem/39194693
Differential Revision: https://reviews.llvm.org/D45382
llvm-svn: 331020
When rebasing https://reviews.llvm.org/D40898 with GCC 5.4 on Solaris 11.4, I ran
into a few instances of
In file included from /vol/llvm/src/compiler-rt/local/test/asan/TestCases/Posix/asan-symbolize-sanity-test.cc:19:
In file included from /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/string:40:
In file included from /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/bits/char_traits.h:39:
In file included from /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/bits/stl_algobase.h:64:
In file included from /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/bits/stl_pair.h:59:
In file included from /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/bits/move.h:57:
/usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/type_traits:311:39: error: __float128 is not supported on this target
struct __is_floating_point_helper<__float128>
^
during make check-all. The line above is inside
#if !defined(__STRICT_ANSI__) && defined(_GLIBCXX_USE_FLOAT128)
template<>
struct __is_floating_point_helper<__float128>
: public true_type { };
#endif
While the libstdc++ header indicates support for __float128, clang does not, but
should. The following patch implements this and fixed those errors.
Differential Revision: https://reviews.llvm.org/D41240
llvm-svn: 330572
Summary:
Under some conditions, LinkageComputer can get the visibility for
ClassTemplateSpecializationDecl wrong because it failed to find the Decl
that has the explicit visibility.
This fixes:
llvm.org/bugs/pr36810
rdar://problem/38080953
Reviewers: rsmith, arphaman, doug.gregor
Reviewed By: doug.gregor
Subscribers: doug.gregor, cfe-commits
Differential Revision: https://reviews.llvm.org/D44670
llvm-svn: 330338
have a non-trivial destructor.
This fixes a bug introduced in r328731 where CodeGen emits calls to
synthesized destructors for non-trivial C structs in C++ mode when the
struct passed to EmitCallArg doesn't have a non-trivial destructor.
Under Microsoft's ABI, ASTContext::isParamDestroyedInCallee currently
always returns true, so it's necessary to check whether the struct has a
non-trivial destructor before pushing a cleanup in EmitCallArg.
This fixes PR37146.
llvm-svn: 330304
Enables _Float16 on Windows by creating a mangling
mechanism in MicrosoftMangle. It accomplishes this by
mangling as a structure type of __clang::_Float16, similar
to how Complex works.
Patch By: mibintc
Differential Revision: https://reviews.llvm.org/D45738
llvm-svn: 330225
When emitting CodeView debug information, compiler-generated thunk routines
should be emitted using S_THUNK32 symbols instead of S_GPROC32_ID symbols so
Visual Studio can properly step into the user code. This initial support only
handles standard thunk ordinals.
Differential Revision: https://reviews.llvm.org/D43838
llvm-svn: 330132
Found via codespell -q 3 -I ../clang-whitelist.txt
Where whitelist consists of:
archtype
cas
classs
checkk
compres
definit
frome
iff
inteval
ith
lod
methode
nd
optin
ot
pres
statics
te
thru
Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few
files that have dubious fixes reverted.)
Differential revision: https://reviews.llvm.org/D44188
llvm-svn: 329399
the tail padding is not reused.
We track on the AggValueSlot (and through a couple of other
initialization actions) whether we're dealing with an object that might
share its tail padding with some other object, so that we can avoid
emitting stores into the tail padding if that's the case. We still
widen stores into tail padding when we can do so.
Differential Revision: https://reviews.llvm.org/D45306
llvm-svn: 329342
Summary:
"-fmerge-all-constants" is a non-conforming optimization and should not
be the default. It is also causing miscompiles when building Linux
Kernel (https://lkml.org/lkml/2018/3/20/872).
Fixes PR18538.
Reviewers: rjmccall, rsmith, chandlerc
Reviewed By: rsmith, chandlerc
Subscribers: srhines, cfe-commits
Differential Revision: https://reviews.llvm.org/D45289
llvm-svn: 329300
Microsoft has reserved 'U' for the PreserveMostCC which is used in the
swift runtime. Add support for this. This allows the swift runtime to
be built for Windows again.
llvm-svn: 329025
Summary:
The following class hierarchy requires that we be able to emit a
this-adjusting thunk for B::foo in C's vftable:
struct Incomplete;
struct A {
virtual A* foo(Incomplete p) = 0;
};
struct B : virtual A {
void foo(Incomplete p) override;
};
struct C : B { int c; };
This TU is valid, but lacks a definition of 'Incomplete', which makes it
hard to build a thunk for the final overrider, B::foo.
Before this change, Clang gives up attempting to emit the thunk, because
it assumes that if the parameter types are incomplete, it must be
emitting the thunk for optimization purposes. This is untrue for the MS
ABI, where the implementation of B::foo has no idea what thunks C's
vftable may require. Clang needs to emit the thunk without necessarily
having access to the complete prototype of foo.
This change makes Clang emit a musttail variadic call when it needs such
a thunk. I call these "unprototyped" thunks, because they only prototype
the "this" parameter, which must always come first in the MS C++ ABI.
These thunks work, but they create ugly LLVM IR. If the call to the
thunk is devirtualized, it will be a call to a bitcast of a function
pointer. Today, LLVM cannot inline through such a call, but I want to
address that soon, because we also use this pattern for virtual member
pointer thunks.
This change also implements an old FIXME in the code about reusing the
thunk's computed CGFunctionInfo as much as possible. Now we don't end up
computing the thunk's mangled name and arranging it's prototype up to
around three times.
Fixes PR25641
Reviewers: rjmccall, rsmith, hans
Subscribers: Prazek, cfe-commits
Differential Revision: https://reviews.llvm.org/D45112
llvm-svn: 329009
The problem with the previous logic was that there might not be any
explicit copy/move constructor declarations, e.g. if the type is
trivial and we've never type-checked a copy of it. Relying on Sema's
computation seems much more reliable.
Also, I believe Richard's recommendation is exactly the rule we use
now on the Itanium ABI, modulo the trivial_abi attribute (which this
change of course fixes our handling of in Swift).
This does mean that we have a less portable rule for deciding
indirectness for swiftcall. I would prefer it if we just applied the
Itanium rule universally under swiftcall, but in the meantime, I need
to fix this bug.
This only arises when defining functions with class-type arguments
in C++, as we do in the Swift runtime. It doesn't affect normal Swift
operation because we don't import code as C++.
llvm-svn: 328942
ObjC and ObjC++ pass non-trivial structs in a way that is incompatible
with each other. For example:
typedef struct {
id f0;
__weak id f1;
} S;
// this code is compiled in c++.
extern "C" {
void foo(S s);
}
void caller() {
// the caller passes the parameter indirectly and destructs it.
foo(S());
}
// this function is compiled in c.
// 'a' is passed directly and is destructed in the callee.
void foo(S a) {
}
This patch fixes the incompatibility by passing and returning structs
with __strong or weak fields using the C ABI in C++ mode. __strong and
__weak fields in a struct do not cause the struct to be destructed in
the caller and __strong fields do not cause the struct to be passed
indirectly.
Also, this patch fixes the microsoft ABI bug mentioned here:
https://reviews.llvm.org/D41039?id=128767#inline-364710
rdar://problem/38887866
Differential Revision: https://reviews.llvm.org/D44908
llvm-svn: 328731
We were assuming that vbtable indices were assigned in layout order in
our comparison, which is not the case. When a virtual method, such as
the destructor, appears in multiple vftables, the vftable that appears
first in object layout order is the one that points to the main
implementation of that method. The later vftables use thunks.
In this layout, we adjusted "this" in the main implementation by the
amount that is appropriate for 'B' instead of 'A', even though the main
implementation is found in D's vftable for A:
struct A {
virtual ~A() {}
};
struct B {
virtual ~B() {}
};
struct C : virtual B {};
struct D : virtual A, C {};
D's layout looks like:
0 D subobject (empty)
0 C base suboject
8 A base subobject
16 B base subobject
With this fix, we correctly adjust by -8 in D's deleting destructor
instead of -16.
Fixes PR36921.
llvm-svn: 328723
Declaring "_Pragma("clang optimize off")" before the body of a
function with a lambda leads to the lambda functions in the body
not being affected.
Differential Revision: https://reviews.llvm.org/D43821
llvm-svn: 328494
The issues was that we were setting hidden visibility if, when
processing a hidden class, we found out that we needed to emit a
reference to a vtable provided by the standard library.
Original message:
Set dso_local on vtables.
llvm-svn: 328288
Summary:
Libc++'s default allocator uses `__builtin_operator_new` and `__builtin_operator_delete` in order to allow the calls to new/delete to be ellided. However, libc++ now needs to support over-aligned types in the default allocator. In order to support this without disabling the existing optimization Clang needs to support calling the aligned new overloads from the builtins.
See llvm.org/PR22634 for more information about the libc++ bug.
This patch changes `__builtin_operator_new`/`__builtin_operator_delete` to call any usual `operator new`/`operator delete` function. It does this by performing overload resolution with the arguments passed to the builtin to determine which allocation function to call. If the selected function is not a usual allocation function a diagnostic is issued.
One open issue is if the `align_val_t` overloads should be considered "usual" when `LangOpts::AlignedAllocation` is disabled.
In order to allow libc++ to detect this new behavior the value for `__has_builtin(__builtin_operator_new)` has been updated to `201802`.
Reviewers: rsmith, majnemer, aaron.ballman, erik.pilkington, bogner, ahatanak
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43047
llvm-svn: 328134
Digging through commit logs, it appears the checks in this block predate
`inline` class variables. With them, we fail to emit dynamic
initializers for members that don't have an explicit initializer, and we
won't go out of our way to instantiate the class denoted by
`Var->getType()`.
Fixes PR35599.
llvm-svn: 327945
source expressions when iterating over a PseudoObjectExpr's semantic
subexpression list.
Previously the loop in emitPseudoObjectExpr would emit the IR for each
OpaqueValueExpr that was in a PseudoObjectExpr's semantic-form
expression list and use the result when the OpaqueValueExpr later
appeared in other expressions. This caused an assertion failure when
AggExprEmitter tried to copy the result of an OpaqueValueExpr and the
copied type didn't have trivial copy/move constructors or assignment
operators.
This patch adds flag IsUnique to OpaqueValueExpr which indicates it is a
unique reference to its source expression (it is not used in multiple
places). The loop in emitPseudoObjectExpr ignores OpaqueValueExprs that
are unique and CodeGen visitors simply traverse the source expressions
of such OpaqueValueExprs.
rdar://problem/34363596
Differential Revision: https://reviews.llvm.org/D39562
llvm-svn: 327939
Summary:
Previously we tried too hard to uphold the fiction that destructor
variants work like they do on Itanium throughout the ABI-neutral parts
of clang. This lead to MS C++ ABI incompatiblities and other bugs. Now,
-mconstructor-aliases will no longer control this ABI detail, and clang
-cc1's LLVM IR output will be this much closer to the clang driver's.
Based on a patch by Zahira Ammarguellat:
https://reviews.llvm.org/D39063
I've tried to move the logic that Zahira added into MicrosoftCXXABI.cpp.
There is only one ABI-specific detail sticking out, and that is in
CodeGenModule::getAddrOfCXXStructor, where we collapse complete dtors to
base dtors in the MS ABI.
This fixes PR32990.
Reviewers: erichkeane, zahiraam, majnemer, rjmccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D44505
llvm-svn: 327732
Since there is no reliable way to change the AST depth of this test by supported stack size
of the test environment, remove this test for now.
llvm-svn: 327578
In this particular case it would be possible to just add an else with
CGM.setDSOLocal(GV), but it seems better to have as many callers as
possible just call setGVProperties so that we can centralize the logic
there.
This patch then makes setGVProperties able to handle null Decls.
llvm-svn: 327543
Simplify the dispatching for the personality routines. This really had
no test coverage previously, so add test coverage for the various cases.
This turns out to be pretty complicated as the various languages and
models interact to change personalities around.
You really should feel bad for the compiler if you are using exceptions.
There is no reason for this type of cruelty.
llvm-svn: 327105
...that have already been constructed (e.g., in inner classes) while parsing the
class definition. They would otherwise lack any DLLAttr inherited from the
class, which are only set here (called from Sema::CheckCompletedClass) after the
class definition has been parsed completely.
Differential revision: https://reviews.llvm.org/D16632
llvm-svn: 326990
Before this, we'd only emit lifetime.ends for these temps in
non-exceptional paths. This potentially made our stack larger than it
needed to be for any code that follows an EH cleanup. e.g. in
```
struct Foo { char cs[32]; };
void escape(void *);
struct Bar { ~Bar() { char cs[64]; escape(cs); } };
Foo getFoo();
void baz() {
Bar b;
getFoo();
}
```
baz() would require 96 bytes of stack, since the temporary from getFoo()
only had a lifetime.end on the non-exceptional path.
This also makes us keep hold of the Value* returned by
EmitLifetimeStart, so we don't have to remake it later.
llvm-svn: 326988
We already have a mangling for the __unaligned qualifier, we just have
to call Qualifiers::getFromCVRUMask instead of getFromCVRMask.
PR36638
llvm-svn: 326971
The indirect function argument is in alloca address space in LLVM IR. However,
during Clang codegen for C++, the address space of indirect function argument
should match its address space in the source code, i.e., default addr space, even
for indirect argument. This is because destructor of the indirect argument may
be called in the caller function, and address of the indirect argument may be
taken, in either case the indirect function argument is expected to be in default
addr space, not the alloca address space.
Therefore, the indirect function argument should be mapped to the temp var
casted to default address space. The caller will cast it to alloca addr space
when passing it to the callee. In the callee, the argument is also casted to the
default address space and used.
CallArg is refactored to facilitate this fix.
Differential Revision: https://reviews.llvm.org/D34367
llvm-svn: 326946
The original revert was done in r326869, since reverting r326602 broke
the test added by this.
The new test should be less dependent on r326602.
llvm-svn: 326872
The patch fixes a number of bugs related to parameter indexing in
attributes:
* Parameter indices in some attributes (argument_with_type_tag,
pointer_with_type_tag, nonnull, ownership_takes, ownership_holds,
and ownership_returns) are specified in source as one-origin
including any C++ implicit this parameter, were stored as
zero-origin excluding any this parameter, and were erroneously
printing (-ast-print) and confusingly dumping (-ast-dump) as the
stored values.
* For alloc_size, the C++ implicit this parameter was not subtracted
correctly in Sema, leading to assert failures or to silent failures
of __builtin_object_size to compute a value.
* For argument_with_type_tag, pointer_with_type_tag, and
ownership_returns, the C++ implicit this parameter was not added
back to parameter indices in some diagnostics.
This patch fixes the above bugs and aims to prevent similar bugs in
the future by introducing careful mechanisms for handling parameter
indices in attributes. ParamIdx stores a parameter index and is
designed to hide the stored encoding while providing accessors that
require each use (such as printing) to make explicit the encoding that
is needed. Attribute declarations declare parameter index arguments
as [Variadic]ParamIdxArgument, which are exposed as ParamIdx[*]. This
patch rewrites all attribute arguments that are processed by
checkFunctionOrMethodParameterIndex in SemaDeclAttr.cpp to be declared
as [Variadic]ParamIdxArgument. The only exception is xray_log_args's
argument, which is encoded as a count not an index.
Differential Revision: https://reviews.llvm.org/D43248
llvm-svn: 326602
This is the next step in setting dso_local for COFF.
The patches changes setGVProperties to first set dllimport/dllexport
and changes a few cases that were setting dllimport/dllexport
manually. With this a few more GVs are marked dso_local.
llvm-svn: 326397
Fix for PR32992. Static const classes not exported.
Patch by zahiraam!
(This re-lands the commit, but using S.MarkVariableReferenced instead of
S.PendingInstantiations.push_back, and with an additional test.)
Differential Revision: https://reviews.llvm.org/D42968
llvm-svn: 326089
The tests that failed on a windows host have been fixed.
Original message:
Start setting dso_local for COFF.
With this there are still some GVs where we don't set dso_local
because setGVProperties is never called. I intend to fix that in
followup commits. This is just the bare minimum to teach
shouldAssumeDSOLocal what it should do for COFF.
llvm-svn: 325940
With this there are still some GVs where we don't set dso_local
because setGVProperties is never called. I intend to fix that in
followup commits. This is just the bare minimum to teach
shouldAssumeDSOLocal what it should do for COFF.
llvm-svn: 325915
When using blocks with C++ on Windows x86, it is possible to have the
block literal be pushed into the inalloca'ed parameters. Teach IRGen to
handle the case properly by extracting the block literal from the
inalloca parameter. This fixes the use of blocks with C++ on Windows
x86.
llvm-svn: 325724
This broke Clang bootstrap on Windows, PR36453.
> This handles them exactly the same way that we handle const integral
> static data members with inline definitions, which is what MSVC does.
>
> As a follow-up, now that we have a way to mark variables inline in the
> AST, we should consider marking them implicitly inline there instead of
> only treating them as inline in CodeGen. Unfortunately, this breaks a
> lot of dllimport test cases, so that is future work for now.
>
> Fixes PR36125.
llvm-svn: 325576
This handles them exactly the same way that we handle const integral
static data members with inline definitions, which is what MSVC does.
As a follow-up, now that we have a way to mark variables inline in the
AST, we should consider marking them implicitly inline there instead of
only treating them as inline in CodeGen. Unfortunately, this breaks a
lot of dllimport test cases, so that is future work for now.
Fixes PR36125.
llvm-svn: 325375
This broke the Chromium build on Windows; see https://crbug.com/812231
> Fix for PR32992. Static const classes not exported.
>
> Patch by zahiraam!
>
> Differential Revision: https://reviews.llvm.org/D42968
llvm-svn: 325133
Summary:
This patch also adds the 'DW_AT_artificial' flag to the generated variable.
Addresses the issues mentioned in http://llvm.org/PR30553.
Reviewers: CarlosAlbertoEnciso, probinson, aprantl
Reviewed By: aprantl
Subscribers: JDevlieghere, cfe-commits
Differential Revision: https://reviews.llvm.org/D43189
llvm-svn: 324988
Summary:
Fixes PR36247, which is where WinEHPrepare replaces inline asm in
funclets with unreachable.
Make getBundlesForFunclet return by value to simplify some call sites.
Reviewers: smeenai, majnemer
Subscribers: eraman, cfe-commits
Differential Revision: https://reviews.llvm.org/D43033
llvm-svn: 324689
The difference from the previous try is that we no longer directly
access function declarations from position independent executables. It
should work, but currently doesn't with some linkers.
It now includes a fix to not mark available_externally definitions as
dso_local.
Original message:
Start setting dso_local in clang.
This starts adding dso_local to clang.
The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go
away. My objective for now is to move enough of it to clang to remove
the need for the TargetMachine one to handle PIE copy relocations and
-fno-plt. With that it should then be easy to implement a
-fno-copy-reloc in clang.
This patch just adds the cases where we assume a symbol to be local
based on the file being compiled for an executable or a shared
library.
llvm-svn: 324535
This reverts commit r324500.
The bots found two failures:
ThreadSanitizer-x86_64 :: Linux/pie_no_aslr.cc
ThreadSanitizer-x86_64 :: pie_test.cc
when using gold. The issue is a limitation in gold when building pie
binaries. I will investigate how to work around it.
llvm-svn: 324505
It now includes a fix to not mark available_externally definitions as
dso_local.
Original message:
Start setting dso_local in clang.
This starts adding dso_local to clang.
The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go
away. My objective for now is to move enough of it to clang to remove
the need for the TargetMachine one to handle PIE copy relocations and
-fno-plt. With that it should then be easy to implement a
-fno-copy-reloc in clang.
This patch just adds the cases where we assume a symbol to be local
based on the file being compiled for an executable or a shared
library.
llvm-svn: 324500
This patch:
* fixes an incorrect sign-extension of unsigned values, when emitting
debug info metadata for enumerators
* the enumerators metadata is created with a flag, which determines
interpretation of the value bits (signed or unsigned)
* the enumerations metadata contains the underlying integer type and a
flag, indicating whether this is a C++ "fixed enum"
Differential Revision: https://reviews.llvm.org/D42736
llvm-svn: 324490
Microsoft has reserved the identifier 'S' as the swift calling
convention. Decorate the symbols appropriately. This enables swift on
Windows.
llvm-svn: 324439
This change reduces the live range of the loaded function pointer,
resulting in a slight code size decrease (~10KB in clang), and also
improves the security of CFI for virtual calls by making it less
likely that the function pointer will be spilled, and ensuring that
it is not spilled across a function call boundary.
Fixes PR35353.
Differential Revision: https://reviews.llvm.org/D42725
llvm-svn: 324286
The 'trivial_abi' attribute can be applied to a C++ class, struct, or
union. It makes special functions of the annotated class (the destructor
and copy/move constructors) to be trivial for the purpose of calls and,
as a result, enables the annotated class or containing classes to be
passed or returned using the C ABI for the underlying type.
When a type that is considered trivial for the purpose of calls despite
having a non-trivial destructor (which happens only when the class type
or one of its subobjects is a 'trivial_abi' class) is passed to a
function, the callee is responsible for destroying the object.
For more background, see the discussions that took place on the mailing
list:
http://lists.llvm.org/pipermail/cfe-dev/2017-November/055955.htmlhttp://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/thread.html#214043
rdar://problem/35204524
Differential Revision: https://reviews.llvm.org/D41039
llvm-svn: 324269
Summary:
Previously, Clang only emitted label names in assert builds.
However there is a CC1 option -discard-value-names that should have been used to control emission instead.
This patch removes the NDEBUG preprocessor block and instead allows LLVM to handle removing the names in accordance with the option.
Reviewers: erichkeane, aaron.ballman, majnemer
Reviewed By: aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42829
llvm-svn: 324127
This starts adding dso_local to clang.
The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go
away. My objective for now is to move enough of it to clang to remove
the need for the TargetMachine one to handle PIE copy relocations and
-fno-plt. With that it should then be easy to implement a
-fno-copy-reloc in clang.
This patch just adds the cases where we assume a symbol to be local
based on the file being compiled for an executable or a shared
library.
llvm-svn: 324107
This fixes building Qt as shared libraries with clang in MinGW
mode; previously subclasses of the QObjectData class (in other
DLLs than the base DLL) failed to find the typeinfo symbols
(that neither were emitted in the base DLL nor in the DLL
containing the subclass).
If the virtual destructor in the newly added testcase wouldn't
be pure (or if there'd be another non-pure virtual method),
it'd be a key function and things would work out even before this
change. Make sure to locally emit the typeinfo for these classes
as well.
This matches what GCC does in this specific testcase.
This fixes the root issue that spawned PR35146. (The difference
to GCC that is initially described in that bug still is present
though.)
Differential Revision: https://reviews.llvm.org/D42641
llvm-svn: 324059
Summary:
This patch enables debugging of C99 VLA types by generating more precise
LLVM Debug metadata, using the extended DISubrange 'count' field that
takes a DIVariable.
This should implement:
Bug 30553: Debug info generated for arrays is not what GDB expects (not as good as GCC's)
https://bugs.llvm.org/show_bug.cgi?id=30553
Reviewers: echristo, aprantl, dexonsmith, clayborg, pcc, kristof.beyls, dblaikie
Reviewed By: aprantl
Subscribers: jholewinski, schweitz, davide, fhahn, JDevlieghere, cfe-commits
Differential Revision: https://reviews.llvm.org/D41698
llvm-svn: 323952
Summary:
This change is step three in the series of changes to remove alignment argument from
memcpy/memmove/memset in favour of alignment attributes. Steps:
Step 1) Remove alignment parameter and create alignment parameter attributes for
memcpy/memmove/memset. ( rL322965, rC322964, rL322963 )
Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing
source and dest alignments. ( rL323597 )
Step 3) Update Clang to use the new IRBuilder API.
Step 4) Update Polly to use the new IRBuilder API.
Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API,
and those that use use MemIntrinsicInst::[get|set]Alignment() to use getDestAlignment()
and getSourceAlignment() instead.
Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the
MemIntrinsicInst::[get|set]Alignment() methods.
Reference
http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.htmlhttp://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html
Reviewers: rjmccall
Subscribers: jyknight, nemanjai, nhaehnle, javed.absar, sbc100, aheejin, kbarton, fedor.sergeev, cfe-commits
Differential Revision: https://reviews.llvm.org/D41677
llvm-svn: 323617
constructor.
Previously, clang would emit an over-aligned (16-byte) store to
initialize B::x in B's base constructor when compiling the following
code:
struct A {
__attribute__((aligned(16))) double data1;
};
struct B : public virtual A {
B() : x(123) {}
double a;
int x;
};
struct C : public virtual B {};
void test() { B b; C c; }
This was happening because the code in IRGen that does member
initialization was using the alignment of a complete object instead of
the non-virtual alignment.
This commit fixes the bug.
rdar://problem/36382481
Differential Revision: https://reviews.llvm.org/D42521
llvm-svn: 323578
Hidden visibility is almost the opposite of dllimport. We were
producing them before (dllimport wins in the existing llvm
implementation), but now the llvm verifier produces an error.
llvm-svn: 323361
This is to fix the bug reported in https://bugs.llvm.org/show_bug.cgi?id=34347#c6.
Currently, all MaxAtomicInlineWidth of x86-32 targets are set to 64. However,
i386 doesn't support any cmpxchg related instructions. i486 only supports cmpxchg.
So in this patch MaxAtomicInlineWidth is reset as follows:
For i386, the MaxAtomicInlineWidth should be 0 because no cmpxchg is supported.
For i486, the MaxAtomicInlineWidth should be 32 because it supports cmpxchg.
For others 32 bits x86 cpu, the MaxAtomicInlineWidth should be 64 because of cmpxchg8b.
Differential Revision: https://reviews.llvm.org/D42154
llvm-svn: 323281
When a function taking transparent union is declared as taking one of
union members earlier in the translation unit, clang would hit an
"Invalid cast" assertion during EmitFunctionProlog. This case
corresponds to function f1 in test/CodeGen/transparent-union-redecl.c.
We decided to cast i32 to union because after merging function
declarations function parameter type becomes int,
CGFunctionInfo::ArgInfo type matches with ABIArgInfo type, so we decide
it is a trivial case. But these types should also be castable to
parameter declaration type which is not the case here.
Now the fix is in converting from ABIArgInfo type to VarDecl type and using
argument demotion when necessary.
Additional tests in Sema/transparent-union.c capture current behavior and make
sure there are no regressions.
rdar://problem/34949329
Reviewers: rjmccall, rafael
Reviewed By: rjmccall
Subscribers: aemerson, cfe-commits, kristof.beyls, ahatanak
Differential Revision: https://reviews.llvm.org/D41311
llvm-svn: 323156
Summary:
Upstream LLVM is changing the the prototypes of the @llvm.memcpy/memmove/memset
intrinsics. This change updates the Clang tests for this change.
The @llvm.memcpy/memmove/memset intrinsics currently have an explicit argument
which is required to be a constant integer. It represents the alignment of the
dest (and source), and so must be the minimum of the actual alignment of the
two.
This change removes the alignment argument in favour of placing the alignment
attribute on the source and destination pointers of the memory intrinsic call.
For example, code which used to read:
call void @llvm.memcpy.p0i8.p0i8.i32(i8* %dest, i8* %src, i32 100, i32 4, i1 false)
will now read
call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 4 %dest, i8* align 4 %src, i32 100, i1 false)
At this time the source and destination alignments must be the same (Step 1).
Step 2 of the change, to be landed shortly, will relax that contraint and allow
the source and destination to have different alignments.
llvm-svn: 322964
The standard says:
[expr.static.cast] p11: "If the prvalue of type “pointer to cv1 B” points to a B
that is actually a subobject of an object of type D, the resulting pointer points
to the enclosing object of type D. Otherwise, the behavior is undefined."
Therefore, the GEP must be inbounds.
This should solve the failure to optimize away a null check shown in PR35909:
https://bugs.llvm.org/show_bug.cgi?id=35909
Differential Revision: https://reviews.llvm.org/D42249
llvm-svn: 322950
InitListExprs without types (well, with type 'void') represent not-yet-analyzed
initializer lists; InitListExpr with types fool Sema into thinking they don't
need further analysis in some cases (particularly C++17 copy omission).
llvm-svn: 322414
While updating clang tests for having clang set dso_local I noticed
that:
- There are *a lot* of tests to update.
- Many of the updates are redundant.
They are redundant because a GV is "obviously dso_local". This patch
starts formalizing that a bit by requiring that internal and private
GVs be dso_local too. Since they all are, we don't have to print
dso_local to the textual representation, making it a bit more compact
and easier to read.
llvm-svn: 322318
Summary:
Enable the compile-time flag -fsanitize-memory-use-after-dtor by
default. Note that the run-time option MSAN_OPTIONS=poison_in_dtor=1
still needs to be enabled for destructors to be poisoned.
Reviewers: eugenis, vitalybuka, kcc
Reviewed By: eugenis, vitalybuka
Subscribers: cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D37860
llvm-svn: 322221
GCC's attribute 'target', in addition to being an optimization hint,
also allows function multiversioning. We currently have the former
implemented, this is the latter's implementation.
This works by enabling functions with the same name/signature to coexist,
so that they can all be emitted. Multiversion state is stored in the
FunctionDecl itself, and SemaDecl manages the definitions.
Note that it ends up having to permit redefinition of functions so
that they can all be emitted. Additionally, all versions of the function
must be emitted, so this also manages that.
Note that this includes some additional rules that GCC does not, since
defining something as a MultiVersion function after a usage has been made illegal.
The only 'history rewriting' that happens is if a function is emitted before
it has been converted to a multiversion'ed function, at which point its name
needs to be changed.
Function templates and virtual functions are NOT yet supported (not supported
in GCC either).
Additionally, constructors/destructors are disallowed, but the former is
planned.
llvm-svn: 322028
This implements the DWARF 5 feature described at
http://www.dwarfstd.org/ShowIssue.php?issue=141215.1
This allows a consumer to understand whether a composite data type is
trivially copyable and thus should be passed by value instead of by
reference. The canonical example is being able to distinguish the
following two types:
// S is not trivially copyable because of the explicit destructor.
struct S {
~S() {}
};
// T is a POD type.
struct T {
~T() = default;
};
<rdar://problem/36034993>
Differential Revision: https://reviews.llvm.org/D41039
llvm-svn: 321845
...when such an operation is done on an object during con-/destruction.
This is the cfe part of a patch covering both cfe and compiler-rt.
Differential Revision: https://reviews.llvm.org/D40295
llvm-svn: 321519
When a function taking transparent union is declared as taking one of
union members earlier in the translation unit, clang would hit an
"Invalid cast" assertion during EmitFunctionProlog. This case
corresponds to function f1 in test/CodeGen/transparent-union-redecl.c.
We decided to cast i32 to union because after merging function
declarations function parameter type becomes int,
CGFunctionInfo::ArgInfo type matches with ABIArgInfo type, so we decide
it is a trivial case. But these types should also be castable to
parameter declaration type which is not the case here.
The fix is in checking for the trivial case if ABIArgInfo type matches with
parameter declaration type. It exposed inconsistency that we check
hasScalarEvaluationKind for different types in EmitParmDecl and
EmitFunctionProlog, and comment says they should match.
Additional tests in Sema/transparent-union.c capture current behavior and make
sure there are no regressions.
rdar://problem/34949329
Reviewers: rjmccall, rafael
Reviewed By: rjmccall
Subscribers: aemerson, cfe-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D41311
llvm-svn: 321296
Diagnose 'unreachable' UB when a noreturn function returns.
1. Insert a check at the end of functions marked noreturn.
2. A decl may be marked noreturn in the caller TU, but not marked in
the TU where it's defined. To diagnose this scenario, strip away the
noreturn attribute on the callee and insert check after calls to it.
Testing: check-clang, check-ubsan, check-ubsan-minimal, D40700
rdar://33660464
Differential Revision: https://reviews.llvm.org/D40698
llvm-svn: 321231
Adding the new enumerator forced a bunch more changes into this patch than I
would have liked. The -Wtautological-compare warning was extended to properly
check the new comparison operator, clang-format needed updating because it uses
precedence levels as weights for determining where to break lines (and several
operators increased their precedence levels with this change), thread-safety
analysis needed changes to build its own IL properly for the new operator.
All "real" semantic checking for this operator has been deferred to a future
patch. For now, we use the relational comparison rules and arbitrarily give
the builtin form of the operator a return type of 'void'.
llvm-svn: 320707
Under the Microsoft ABI, it is possible for an object not to have
a virtual table pointer of its own if all of its virtual functions
were introduced by virtual bases. In that case, we need to load the
vtable pointer from one of the virtual bases and perform the type
check using its type.
Differential Revision: https://reviews.llvm.org/D41036
llvm-svn: 320638
This commit fixes a bug in IRGen where it generates completely broken
code for __fp16 vectors on X86. For example when the following code is
compiled:
half4 hv0, hv1, hv2; // these are vectors of __fp16.
void foo221() {
hv0 = hv1 + hv2;
}
clang generates the following IR, in which two i16 vectors are added:
@hv1 = common global <4 x i16> zeroinitializer, align 8
@hv2 = common global <4 x i16> zeroinitializer, align 8
@hv0 = common global <4 x i16> zeroinitializer, align 8
define void @foo221() {
%0 = load <4 x i16>, <4 x i16>* @hv1, align 8
%1 = load <4 x i16>, <4 x i16>* @hv2, align 8
%add = add <4 x i16> %0, %1
store <4 x i16> %add, <4 x i16>* @hv0, align 8
ret void
}
To fix the bug, this commit uses the code committed in r314056, which
modified clang to promote and truncate __fp16 vectors to and from float
vectors in the AST. It also fixes another IRGen bug where a short value
is assigned to an __fp16 variable without any integer-to-floating-point
conversion, as shown in the following example:
__fp16 a;
short b;
void foo1() {
a = b;
}
@b = common global i16 0, align 2
@a = common global i16 0, align 2
define void @foo1() #0 {
%0 = load i16, i16* @b, align 2
store i16 %0, i16* @a, align 2
ret void
}
rdar://problem/20625184
Differential Revision: https://reviews.llvm.org/D40112
llvm-svn: 320215
whether they have an initializer.
We cannot distinguish between a declaration of a variable template
specialization and a definition of one that lacks an initializer without this,
and would previously mistake the latter for the former.
llvm-svn: 319605
This matches MSVC's behaviour, and we already do it for class templates
since r270897.
Differential revision: https://reviews.llvm.org/D40621
llvm-svn: 319386
Fixes regression introduced by r319297. MSVC environments still use SEH
unwind opcodes but they should use the Microsoft C++ EH personality, not
the mingw one.
llvm-svn: 319363
This is a re-apply of r319294.
adds -fseh-exceptions and -fdwarf-exceptions flags
clang will check if the user has specified an exception model flag,
in the absense of specifying the exception model clang will then check
the driver default and append the model flag for that target to cc1
-fno-exceptions has a higher priority then specifying the model
move __SEH__ macro definitions out of Targets into InitPreprocessor
behind the -fseh-exceptions flag
move __ARM_DWARF_EH__ macrodefinitions out of verious targets and into
InitPreprocessor behind the -fdwarf-exceptions flag and arm|thumb check
remove unused USESEHExceptions from the MinGW Driver
fold USESjLjExceptions into a new GetExceptionModel function that
gives the toolchain classes more flexibility with eh models
Reviewers: rnk, mstorsjo
Differential Revision: https://reviews.llvm.org/D39673
llvm-svn: 319297
adds -fseh-exceptions and -fdwarf-exceptions flags
clang will check if the user has specified an exception model flag,
in the absense of specifying the exception model clang will then check
the driver default and append the model flag for that target to cc1
clang cc1 assumes dwarf is the default if none is passed
and -fno-exceptions has a higher priority then specifying the model
move __SEH__ macro definitions out of Targets into InitPreprocessor
behind the -fseh-exceptions flag
move __ARM_DWARF_EH__ macrodefinitions out of verious targets and into
InitPreprocessor behind the -fdwarf-exceptions flag and arm|thumb check
remove unused USESEHExceptions from the MinGW Driver
fold USESjLjExceptions into a new GetExceptionModel function that
gives the toolchain classes more flexibility with eh models
Reviewers: rnk, mstorsjo
Differential Revision: https://reviews.llvm.org/D39673
llvm-svn: 319294
Summary:
This raises __STDCPP_DEFAULT_NEW_ALIGNMENT__ from 8 to 16 on Win64.
This matches platforms that follow the usual `2 * sizeof(void*)`
alignment requirement for malloc. We might want to consider making that
the default rather than relying on long double alignment.
Fixes PR35356
Reviewers: STL_MSFT, rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D40277
llvm-svn: 318723
explicitly instantiated, still emit it with each use.
We don't emit a definition of the member with an explicit instantiation
definition (and indeed it appears that we're not allowed to, since an explicit
instantiation definition does not constitute an odr-use and only odr-use
permits definition for defaulted special members). So we still need to emit a
weak definition with each use.
This also makes defaulted-in-class declarations behave more like
implicitly-declared special members, which matches their design intent.
And it matches the way this problem was solved in GCC.
llvm-svn: 318474
Summary:
The MS ABI convention is that the 'this' pointer on entry is the address
of the vfptr that was used to make the virtual method call. In other
words, the pointer on entry always points to the base subobject that
introduced the virtual method. Consider this hierarchy:
struct A { virtual void f() = 0; };
struct B { virtual void g() = 0; };
struct C : A, B {
void f() override;
void g() override;
};
On entry to C::g, [ER]CX will contain the address of C's B subobject,
and C::g will have to subtract sizeof(A) to recover a pointer to C.
Before this change, we applied this adjustment in the prologue and
stored the new value into the "this" local variable alloca used for
debug info. However, MSVC does not do this, presumably because it is
often profitable to fold the adjustment into later field accesses. This
creates a problem, because the debugger expects the variable to be
unadjusted. Unfortunately, CodeView doesn't have anything like DWARF
expressions for computing variables that aren't in the program anymore,
so we have to declare 'this' to be the unadjusted value if we want the
debugger to see the right value.
This has the side benefit that, in optimized builds, the 'this' pointer
will usually be available on function entry because it doesn't require
any adjustment.
Reviewers: hans
Subscribers: aprantl, cfe-commits
Differential Revision: https://reviews.llvm.org/D40109
llvm-svn: 318440
On e.g. PPC the return value and argument were marked 'signext'. This
makes the test expectations a bit more flexible.
Follow-up to r318199.
llvm-svn: 318214
This updates -mcount to use the new attribute names (LLVM r318195), and
switches over -finstrument-functions to also use these attributes rather
than inserting instrumentation in the frontend.
It also adds a new flag, -finstrument-functions-after-inlining, which
makes the cygprofile instrumentation get inserted after inlining rather
than before.
Differential Revision: https://reviews.llvm.org/D39331
llvm-svn: 318199
GNU frontends don't have options like /MT, /MD
This fixes a few link error regressions with libc++ and libc++abi
Reviewers: rnk, mstorsjo, compnerd
Differential Revision: https://reviews.llvm.org/D33620
llvm-svn: 317398
Added support for regcall as default calling convention. Also added code to
exclude main when applying default calling conventions.
Patch-By: eandrews
Differential Revision: https://reviews.llvm.org/D39210
llvm-svn: 317268
The cloning happens before all metadata nodes are resolved. Prevent the value
mapper from running into unresolved or temporary MD nodes.
Differential Revision: https://reviews.llvm.org/D39396
llvm-svn: 317047
Summary:
This change allows generalizing pointers in type signatures used for
cfi-icall by enabling the -fsanitize-cfi-icall-generalize-pointers flag.
This works by 1) emitting an additional generalized type signature
metadata node for functions and 2) llvm.type.test()ing for the
generalized type for translation units with the flag specified.
This flag is incompatible with -fsanitize-cfi-cross-dso because it would
require emitting twice as many type hashes which would increase artifact
size.
Reviewers: pcc, eugenis
Reviewed By: pcc
Subscribers: kcc
Differential Revision: https://reviews.llvm.org/D39358
llvm-svn: 317044
For non-zero alloca addr space, alloca is usually casted to default addr
space immediately.
For non-vla, alloca is inserted at AllocaInsertPt, therefore the addr
space cast should also be insterted at AllocaInsertPt. However,
for vla, alloca is inserted at the current insertion point of IRBuilder,
therefore the addr space cast should also inserted at the current
insertion point of IRBuilder.
Currently clang always insert addr space cast at AllocaInsertPt, which
causes invalid IR.
This patch fixes that.
Differential Revision: https://reviews.llvm.org/D39374
llvm-svn: 316909
OpaqueValueExpr in a GNU binary conditional expression.
It's not meaningful for a non-materialized temporary object to be used as a
common subexpression of multiple expressions.
llvm-svn: 316836
Summary:
Clang typically warns that in the following class hierarchy, 'A' is
inaccessible because there is no series of casts that the user can
write to access it unambiguously:
struct A { };
struct B : A { };
struct C : A, B { };
MSVC allows the user to convert from C* to A*, though, and we've
encountered this issue in the latest Windows SDK headers.
This patch allows this conversion when -fms-compatibility is set and
adds a warning for it under -Wmicrosoft-inaccessible-base.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D39389
llvm-svn: 316807
Fastcall doesn't support variadic function calls, so
setting the default calling convention to Fastcall would
result in incorrect code being emitted for these conditions.
This patch adds a 'variadic' test to the default calling conv
test, as well as fixes the behavior of fastcall.
llvm-svn: 316528
instantiation declarations if they are usable from constant expressions.
We are permitted to instantiate in these cases, and required to do so in order
to have an initializer available for use within constant evaluation.
llvm-svn: 316136
Currently all the consecutive bitfields are wrapped as a large integer unless there is unamed zero sized bitfield in between. The patch provides an alternative manner which makes the bitfield to be accessed as separate memory location if it has legal integer width and is naturally aligned. Such separate bitfield may split the original consecutive bitfields into subgroups of consecutive bitfields, and each subgroup will be wrapped as an integer. Now This is all controlled by an option -ffine-grained-bitfield-accesses. The alternative of bitfield access manner can improve the access efficiency of those bitfields with legal width and being aligned, but may reduce the chance of load/store combining of other bitfields, so it depends on how the bitfields are defined and actually accessed to choose when to use the option. For now the option is off by default.
Differential revision: https://reviews.llvm.org/D36562
llvm-svn: 315915
The function sanitizer only checks indirect calls through function
pointers. This excludes all non-static member functions (constructor
calls, calls through thunks, etc. all use a separate code path). Don't
emit function signatures for functions that won't be checked.
Apart from cutting down on code size, this should fix a regression on
Linux caused by r313096. For context, see the mailing list discussion:
r313096 - [ubsan] Function Sanitizer: Don't require writable text segments
Testing: check-clang, check-ubsan
Differential Revision: https://reviews.llvm.org/D38913
llvm-svn: 315786
This feature is not (yet) approved by the C++ committee, so this is liable to
be reverted or significantly modified based on committee feedback.
No functionality change intended for existing code (a new type must be defined
in namespace std to take advantage of this feature).
llvm-svn: 315662
Fix PR32990 by effectively reverting r283063 and solving it a different
way.
We want to limit the hack to not replace equivalent available_externally
dtors specifically to libc++, which uses always_inline. It seems certain
versions of libc++ do not provide all the symbols that an explicit
template instantiation is expected to provide.
If we get to the code that forms a real alias, only *then* check if this
is available_externally, and do that by asking a better question, which
is "is this a declaration for the linker?", because *that's* what means
we can't form an alias to it.
As a follow-on simplification, remove the InEveryTU parameter. Its last
use guarded this code for forming aliases, but we should never form
aliases to declarations, regardless of what we know about every TU.
llvm-svn: 315656
This is a re-commit of r315025, but making sure to only apply this to
specializations of class template member functions; i.e. not when the function
itself is a template.
llvm-svn: 315330
Don't emit alignment checks which the IR constant folder throws away.
I've tested this out on X86FastISel.cpp. While this doesn't decrease
end-to-end compile-time significantly, it results in 122 fewer type
checks (1% reduction) overall, without adding any real complexity.
Differential Revision: https://reviews.llvm.org/D37544
llvm-svn: 314752
to have child entries describing the template parameters. This will
be on by default for SCE tuning.
Differential Revision: https://reviews.llvm.org/D14358
llvm-svn: 314444
Summary:
This is the follow-up patch to D37924.
This change refactors clang to use the the newly added section headers
in SpecialCaseList to specify which sanitizers blacklists entries
should apply to, like so:
[cfi-vcall]
fun:*bad_vcall*
[cfi-derived-cast|cfi-unrelated-cast]
fun:*bad_cast*
The SanitizerSpecialCaseList class has been added to allow querying by
SanitizerMask, and SanitizerBlacklist and its downstream users have been
updated to provide that information. Old blacklists not using sections
will continue to function identically since the blacklist entries will
be placed into a '[*]' section by default matching against all
sanitizers.
Reviewers: pcc, kcc, eugenis, vsk
Reviewed By: eugenis
Subscribers: dberris, cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D37925
llvm-svn: 314171
This is to fix PR34347. EmitAtomicExpr now only uses alignment information from
Type, instead of Decl, so when the declaration of an atomic variable is marked
to have the alignment equal as its size, EmitAtomicExpr doesn't know about it and
will generate libcall instead of atomic op. The patch uses EmitPointerWithAlignment
to get the precise alignment information.
Differential Revision: https://reviews.llvm.org/D37310
llvm-svn: 314145
This doesn't affect our code generation in any material way -- we already give
such declarations internal linkage from a codegen perspective -- but it has
some subtle effects on code validity.
We suppress the 'L' (internal linkage) marker for mangled names in anonymous
namespaces, because it is redundant (the information is already carried by the
namespace); this deviates from GCC's behavior if a variable or function in an
anonymous namespace is redundantly declared 'static' (where GCC does include
the 'L'), but GCC's behavior is incoherent because such a declaration can be
validly declared with or without the 'static'.
We still deviate from the standard in one regard here: extern "C" declarations
in anonymous namespaces are still granted external linkage. Changing those does
not appear to have been an intentional consequence of the standard change in
DR1113.
llvm-svn: 314037
This is to fix PR31620. MaxAtomicInlineWidth is set to 128 for x86_64. However
for target without cx16 support, 128 atomic operation will generate __sync_*
libcalls. The patch set MaxAtomicInlineWidth to 64 if the target doesn't support
cx16.
Differential Revision: https://reviews.llvm.org/D38046
llvm-svn: 313992
This implements the proposed approach in https://github.com/itanium-cxx-abi/cxx-abi/issues/33
This reinstates r313827, reverted in r313856, with a fix for the 'out-of-bounds
enumeration value' ubsan error in that change.
llvm-svn: 313955
If a function or variable has a type with no linkage (and is not extern "C"),
any use of it requires a definition within the same translation unit; the idea
is that it is not possible to define the entity elsewhere, so any such use is
necessarily an error.
There is an exception, though: some types formally have no linkage but
nonetheless can be referenced from other translation units (for example, this
happens to anonymous structures defined within inline functions). For entities
with those types, we suppress the diagnostic except under -pedantic.
llvm-svn: 313729
This reverts commit r313722.
It looks like compiler-rt/lib/tsan/rtl/tsan_libdispatch_mac.cc cannot be
compiled because some of the functions declared in the file do not match
the ones in the SDK headers (which are annotated with 'noescape').
llvm-svn: 313725
The attribute informs the compiler that the annotated pointer parameter
of a function cannot escape and enables IRGen to attach attribute
'nocapture' to parameters that are annotated with the attribute. That is
the only optimization that currently takes advantage of 'noescape', but
there are other optimizations that will be added later that improves
IRGen for ObjC blocks.
rdar://problem/19886775
Differential Revision: https://reviews.llvm.org/D32210
llvm-svn: 313722
The attribute informs the compiler that the annotated pointer parameter
of a function cannot escape and enables IRGen to attach attribute
'nocapture' to parameters that are annotated with the attribute. That is
the only optimization that currently takes advantage of 'noescape', but
there are other optimizations that will be added later that improves
IRGen for ObjC blocks.
rdar://problem/19886775
Differential Revision: https://reviews.llvm.org/D32520
llvm-svn: 313720
Summary:
To improve CodeView quality for static member functions, we need to make the
static explicit. In addition to a small change in LLVM's CodeViewDebug to
return the appropriate MethodKind, this requires a small change in Clang to
note the staticness in the debug info metadata.
Subscribers: aprantl, hiraditya
Differential Revision: https://reviews.llvm.org/D37715
llvm-svn: 313192
This change will make it possible to use -fsanitize=function on Darwin and
possibly on other platforms. It fixes an issue with the way RTTI is stored into
function prologue data.
On Darwin, addresses stored in prologue data can't require run-time fixups and
must be PC-relative. Run-time fixups are undesirable because they necessitate
writable text segments, which can lead to security issues. And absolute
addresses are undesirable because they break PIE mode.
The fix is to create a private global which points to the RTTI, and then to
encode a PC-relative reference to the global into prologue data.
Differential Revision: https://reviews.llvm.org/D37597
llvm-svn: 313096
Summary:
Microsoft Visual Studio expects debug locations to correspond to
statements. We used to emit locations for expressions nested inside statements.
This would confuse the debugger, causing it to stop multiple times on the
same line and breaking the "step into specific" feature. This change inhibits
the emission of debug locations for nested expressions when emitting CodeView
debug information, unless column information is enabled.
Fixes PR34312.
Reviewers: rnk, zturner
Reviewed By: rnk
Subscribers: majnemer, echristo, aprantl, cfe-commits
Differential Revision: https://reviews.llvm.org/D37529
llvm-svn: 312965
This is to fix PR34347. EmitAtomicExpr now only uses alignment information from
Type, instead of Decl, so when the declaration of an atomic variable is marked
to have the alignment equal as its size, EmitAtomicExpr doesn't know about it and
will generate libcall instead of atomic op. The patch uses EmitPointerWithAlignment
to get the precise alignment information.
Differential Revision: https://reviews.llvm.org/D37310
llvm-svn: 312830
This is to fix PR34347. EmitAtomicExpr now only uses alignment information from
Type, instead of Decl, so when the declaration of an atomic variable is marked
to have the alignment equal as its size, EmitAtomicExpr doesn't know about it and
will generate libcall instead of atomic op. The patch uses EmitPointerWithAlignment
to get the precise alignment information.
Differential Revision: https://reviews.llvm.org/D37310
llvm-svn: 312801
This is a recommit of r312781; in some build configurations
variable names are omitted, so changed the new regression
test accordingly.
llvm-svn: 312794
This adds _Float16 as a source language type, which is a 16-bit floating point
type defined in C11 extension ISO/IEC TS 18661-3.
In follow up patches documentation and more tests will be added.
Differential Revision: https://reviews.llvm.org/D33719
llvm-svn: 312781
By exposing the constant initializer, the optimizer can fold many
of these constructs.
This is a recommit of r311857 that was reverted in r311898 because
an assert was hit when building Chromium.
We have to take into account that the GlobalVariable may be first
created with a different type than the initializer. This can
happen for example when the variable is a struct with tail padding
while the initializer does not have padding. In such case, the
variable needs to be destroyed an replaced with a new one with the
type of the initializer.
Differential Revision: https://reviews.llvm.org/D34992
llvm-svn: 312512
This fixes cases where dynamic classes produced RTTI data with
external linkage, producing linker errors about duplicate symbols.
This touches code close to what was changed in SVN r244266, but
this change doesn't break the tests added in that revision.
The previous version had missed to update CodeGenCXX/virt-dtor-key.cpp,
which had a behaviour change only when running the testsuite on windows.
Differential revision: https://reviews.llvm.org/D37327
llvm-svn: 312306
This fixes cases where dynamic classes produced RTTI data with
external linkage, producing linker errors about duplicate symbols.
This touches code close to what was changed in SVN r244266, but
this change doesn't break the tests added in that revision.
Differential revision: https://reviews.llvm.org/D37206
llvm-svn: 312224
Overriding a method from a virtual base with a covariant return type
consumes a slot from the vftable in the virtual base. This can make it
impossible to implement certain diamond inheritance hierarchies, but we
have to follow along for compatibility in the simple cases.
This patch only affects our vtable dumper and member pointer function
mangling, since all other callers of getMethodVFTableLocation seem to
recompute VBTableIndex instead of using the one in the method location.
Patch by David Majnemer
llvm-svn: 312017
It caused PR759744.
> Emit static constexpr member as available_externally definition
>
> By exposing the constant initializer, the optimizer can fold many
> of these constructs.
>
> Differential Revision: https://reviews.llvm.org/D34992
llvm-svn: 311898
By exposing the constant initializer, the optimizer can fold many
of these constructs.
Differential Revision: https://reviews.llvm.org/D34992
llvm-svn: 311857
This patch adds a flag -fclang-abi-compat that can be used to request that
Clang attempts to be ABI-compatible with some older version of itself.
This is provided on a best-effort basis; right now, this can be used to undo
the ABI change in r310401, reverting Clang to its prior C++ ABI for pass/return
by value of class types affected by that change, and to undo the ABI change in
r262688, reverting Clang to using integer registers rather than SSE registers
for passing <1 x long long> vectors. The intent is that we will maintain this
backwards compatibility path as we make ABI-breaking fixes in future.
The reversion to the old behavior for r310401 is also applied to the PS4 target
since that change is not part of its platform ABI (which is essentially to do
whatever Clang 3.2 did).
llvm-svn: 311823
expressions
C++ allows us to reference static variables through member expressions. Prior to
this commit, non-integer static variables that were referenced using a member
expression were always emitted using lvalue loads. The old behaviour introduced
an inconsistency between regular uses of static variables and member expressions
uses. For example, the following program compiled and linked successfully:
struct Foo {
constexpr static const char *name = "foo";
};
int main() {
return Foo::name[0] == 'f';
}
but this program failed to link because "Foo::name" wasn't found:
struct Foo {
constexpr static const char *name = "foo";
};
int main() {
Foo f;
return f.name[0] == 'f';
}
This commit ensures that constant static variables referenced through member
expressions are emitted in the same way as ordinary static variable references.
rdar://33942261
Differential Revision: https://reviews.llvm.org/D36876
llvm-svn: 311772
Do not sanitize the 'this' pointer of a member call operator for a lambda with
no capture-default, since that call operator can legitimately be called with a
null this pointer from the static invoker function. Any actual call with a null
this pointer should still be caught in the caller (if it is being sanitized).
This reinstates r311589 (reverted in r311680) with the above fix.
llvm-svn: 311695
Summary:
Most DIExpressions are empty or very simple. When they are complex, they
tend to be unique, so checking them inline is reasonable.
This also avoids the need for CodeGen passes to append to the
llvm.dbg.mir named md node.
See also PR22780, for making DIExpression not be an MDNode.
Reviewers: aprantl, dexonsmith, dblaikie
Subscribers: qcolombet, javed.absar, eraman, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D37075
llvm-svn: 311594
constructors when deciding whether classes should be passed indirectly.
This fixes ABI differences between Clang and GCC:
* Previously, Clang ignored the move constructor when making this
determination. It now takes the move constructor into account, per
https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may
seem recent, but the ABI change was agreed on the Itanium C++ ABI
list a long time ago).
* Previously, Clang's behavior when the copy constructor was deleted
was unstable -- depending on whether the lazy declaration of the
copy constructor had been triggered, you might get different behavior.
We now eagerly declare the copy constructor whenever its deletedness
is unclear, and ignore deleted copy/move constructors when looking for
a trivial such constructor.
This also fixes an ABI difference between Clang and MSVC:
* If the copy constructor would be implicitly deleted (but has not been
lazily declared yet), for instance because the class has an rvalue
reference member, we would pass it directly. We now pass such a class
indirectly, matching MSVC.
Based on a patch by Vassil Vassilev, which was based on a patch by Bernd
Schmidt, which was based on a patch by Reid Kleckner!
This is a re-commit of r310401, which was reverted in r310464 due to ARM
failures (which should now be fixed).
llvm-svn: 310983
the class becoming complete and its inline methods being parsed.
This replaces the hack of using the "late parsed template" flag to track member
functions with bodies we've not parsed yet; instead we now use the "will have
body" flag, which carries the desired implication that the function declaration
*is* a definition, and that we've just not parsed its body yet.
llvm-svn: 310776
It was timing out on this test, but for reasons unrelated to the
specific bug it was testing for. Randomly breaking in gdb with `clang
-target i686-windows -fmsc-version=1700` reveals *many* frames from
MicrosoftCXXNameMangler. So, it would seem that some caching is needed
there, as well...
Fingers crossed that specifying a triple is sufficient to work around
this.
llvm-svn: 310444
This is a follow-up to r310436 with actual functional changes. Please
see that commit message for a description of why a cache is appearing
here.
Suggestions for less-bad ways of testing this are appreciated. :)
This fixes PR29160.
llvm-svn: 310437
Converting a _Complex type to a real one simply discards the imaginary part.
This can easily lead to loss of information so for safety (and GCC
compatibility) this patch disallows that when the conversion would be implicit.
The one exception is bool, which actually compares both real and imaginary
parts and so is safe.
llvm-svn: 310427
Previously we limited ourselves to only emitting nested classes, but we
need other kinds of types as well.
This fixes the Visual Studio STL visualizers, so that users can
visualize std::string and other objects.
llvm-svn: 310410
constructors when deciding whether classes should be passed indirectly.
This fixes ABI differences between Clang and GCC:
* Previously, Clang ignored the move constructor when making this
determination. It now takes the move constructor into account, per
https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may
seem recent, but the ABI change was agreed on the Itanium C++ ABI
list a long time ago).
* Previously, Clang's behavior when the copy constructor was deleted
was unstable -- depending on whether the lazy declaration of the
copy constructor had been triggered, you might get different behavior.
We now eagerly declare the copy constructor whenever its deletedness
is unclear, and ignore deleted copy/move constructors when looking for
a trivial such constructor.
This also fixes an ABI difference between Clang and MSVC:
* If the copy constructor would be implicitly deleted (but has not been
lazily declared yet), for instance because the class has an rvalue
reference member, we would pass it directly. We now pass such a class
indirectly, matching MSVC.
llvm-svn: 310401
In r309007, I made -fsanitize=null a hard prerequisite for -fsanitize=vptr. I
did not see the need for the two checks to have separate null checking logic
for the same pointer. I expected the two checks to either always be enabled
together, or to be mutually compatible.
In the mailing list discussion re: r309007 it became clear that that isn't the
case. If a codebase is -fsanitize=vptr clean but not -fsanitize=null clean,
it's useful to have -fsanitize=vptr emit its own null check. That's what this
patch does: with it, -fsanitize=vptr can be used without -fsanitize=null.
Differential Revision: https://reviews.llvm.org/D36112
llvm-svn: 309846
Summary:
Change the condition of this unnecessary packed warning. The packed is unnecessary when
1. the alignment of the struct/class won't alter.
2. the size is unchanged.
3. the offset of each field is the same.
Remove all field-level warning.
Reviewers: chh, akyrtzi, rtrieu
Reviewed By: chh
Subscribers: rsmith, srhines, cfe-commits, xazax.hun
Differential Revision: https://reviews.llvm.org/D34114
llvm-svn: 309750
CodeGenFunction::EmitTypeMetadataCodeForVCall() could output an
llvm.assume(llvm.type.test())when CFI was enabled, optimizing out the
vcall check. This case was only reached when: 1) CFI-vcall was enabled,
2) -fwhole-program-tables was specified, and 3)
-fno-sanitize-trap=cfi-vcall was specified.
Patch by Vlad Tsyrklevich!
Differential Revision: https://reviews.llvm.org/D36013
llvm-svn: 309622
r303175 made changes to have __cxa_allocate_exception return a 16-byte
aligned pointer, so it's no longer necessary to specify a lower
alignment (8-bytes) for exception objects on Darwin.
rdar://problem/32363695
llvm-svn: 309308
The initializer for a static local variable cannot be hot, because it runs at
most once per program. That's not quite the same thing as having a low branch
probability, but under the assumption that the function is invoked many times,
modeling this as a branch probability seems reasonable.
For TLS variables, the situation is less clear, since the initialization side
of the branch can run multiple times in a program execution, but we still
expect initialization to be rare relative to non-initialization uses. It would
seem worthwhile to add a PGO counter along this path to make this estimation
more accurate in future.
For globals with guarded initialization, we don't yet apply any branch weights.
Due to our use of COMDATs, the guard will be reached exactly once per DSO, but
we have no idea how many DSOs will define the variable.
llvm-svn: 309195
std::byte, when defined as an enum, needs to be given special treatment
with regards to its aliasing properties. An array of std::byte is
allowed to be used as storage for other types.
This fixes PR33916.
Differential Revision: https://reviews.llvm.org/D35824
llvm-svn: 309058
The instrumentation generated by -fsanitize=vptr does not null check a
user pointer before loading from it. This causes crashes in the face of
UB member calls (this=nullptr), i.e it's causing user programs to crash
only after UBSan is turned on.
The fix is to make run-time null checking a prerequisite for enabling
-fsanitize=vptr, and to then teach UBSan to reuse these run-time null
checks to make -fsanitize=vptr safe.
Testing: check-clang, check-ubsan, a stage2 ubsan-enabled build
Differential Revision: https://reviews.llvm.org/D35735https://bugs.llvm.org/show_bug.cgi?id=33881
llvm-svn: 309007
Under Windows Itanium, we need to export virtual and non-virtual thunks
if the functions being thunked are exported. These thunks would
previously inherit their dllexport attribute from the declaration, but
r298330 changed declarations to not have dllexport attributes. We
therefore need to add the dllexport attribute to the definition
ourselves now. This is consistent with MinGW GCC's behavior.
This redoes r306770 but limits the logic to Itanium. MicrosoftCXXABI's
setThunkLinkage ensures that thunks aren't exported under that ABI, so
I'm handling this in ItaniumCXXABI's setThunkLinkage for symmetry.
We need to export these thunks because they can be referenced outside
the library they're defined in. For example, if a child class without a
key function inherits from a parent class with a key function, the
parent's thunks will only be defined in the library with the key
function, but the construction vtable for the parent in the child might
be emitted outside the library (since the child doesn't have a key
function), and it needs to reference the parent's thunks.
We don't need to mark these thunks as imported since any references to
them will occur in data, so the compiler can't generate the IAT load
sequence anyway. Instead, we rely on the linker generating import thunks
for the thunks.
Differential Revision: https://reviews.llvm.org/D34972
llvm-svn: 308899
This change is part of the RegCall calling convention support for LLVM.
Existing RegCall implementation was extended to include correct handling of
Complex Long Double type. Complex long double types should be returned/passed
in memory and not register stack. This patch implements this behavior.
Patch by: eandrews
Differential Revision: https://reviews.llvm.org/D35259
llvm-svn: 308769
The uses of alloca may be in different blocks other than the block containing the alloca.
Therefore if the alloca addr space is non-zero and it needs to be casted to default
address space, the cast needs to be inserted in the same BB as the alloca insted of
the current builder insert point since the current insert point may be in a different BB.
Differential Revision: https://reviews.llvm.org/D35438
llvm-svn: 308313
devirtualized.
The code to detect devirtualized calls is already in IRGen, so move the
code to lib/AST and make it a shared utility between Sema and IRGen.
This commit fixes a linkage error I was seeing when compiling the
following code:
$ cat test1.cpp
struct Base {
virtual void operator()() {}
};
template<class T>
struct Derived final : Base {
void operator()() override {}
};
Derived<int> *d;
int main() {
if (d)
(*d)();
return 0;
}
rdar://problem/33195657
Differential Revision: https://reviews.llvm.org/D34301
llvm-svn: 307883
Certain targets (e.g. amdgcn) require global variable to stay in global or constant address
space. In C or C++ global variables are emitted in the default (generic) address space.
This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace
and TargetInfo::getConstantAddressSpace to handle this in a general approach.
It only affects IR generated for amdgcn target.
Differential Revision: https://reviews.llvm.org/D33842
llvm-svn: 307470
Under Windows Itanium, we need to export virtual and non-virtual thunks
if the functions being thunked are exported. These thunks would
previously inherit their dllexport attribute from the declaration, but
r298330 changed declarations to not have dllexport attributes. We
therefore need to add the dllexport attribute to the definition
ourselves now.
Differential Revision: https://reviews.llvm.org/D34850
llvm-svn: 306770
This patch extends the `overloadable` attribute to allow for one
function with a given name to not be marked with the `overloadable`
attribute. The overload without the `overloadable` attribute will not
have its name mangled.
So, the following code is now legal:
void foo(void) __attribute__((overloadable));
void foo(int);
void foo(float) __attribute__((overloadable));
In addition, this patch fixes a bug where we'd accept code with
`__attribute__((overloadable))` inconsistently applied. In other words,
we used to accept:
void foo(void);
void foo(void) __attribute__((overloadable));
But we will do this no longer, since it defeats the original purpose of
requiring `__attribute__((overloadable))` on all redeclarations of a
function.
This breakage seems to not be an issue in practice, since the only code
I could find that had this pattern often looked like:
void foo(void);
void foo(void) __attribute__((overloadable)) __asm__("foo");
void foo(int) __attribute__((overloadable));
...Which can now be simplified by simply removing the asm label and
overloadable attribute from the redeclaration of `void foo(void);`
Differential Revision: https://reviews.llvm.org/D32332
llvm-svn: 306467
When generating the decorated name for a static variable inside a
BlockDecl, construct a scope for the block invocation function that
homes the parameter. This allows for arbitrary nesting of the blocks
even if the variables are shadowed. Furthermore, using this for the name
allows for undname to properly undecorated the name for us. It shows up
as the synthetic __block_invocation function that the compiler emitted
in the local scope.
llvm-svn: 306347
This reverts commit r306137. It has problems on code like this:
struct __declspec(dllimport) Foo {
int a;
int get_a() { return a; }
};
template <int (Foo::*Getter)()> struct HasValue {
int operator()(Foo *p) { return (p->*Getter)(); }
};
int main() {
Foo f;
f.a = 3;
int x = HasValue<&Foo::get_a>()(&f);
}
llvm-svn: 306175
We were already applying the same rules to dllimport function pointers.
David Majnemer added that logic back in r211677 to fix PR20130. We
failed to extend that logic to non-virtual member function pointers,
which are basically function pointers in a struct with some extra
offsets.
Fixes PR33570.
llvm-svn: 306137
In C++ all variables are in default address space. Previously change has been
made to cast automatic variables to default address space. However that is
not sufficient since all temporary variables need to be casted to default
address space.
This patch casts all temporary variables to default address space except those
for passing indirect arguments since they are only used for load/store.
This patch only affects target having non-zero alloca address space.
Differential Revision: https://reviews.llvm.org/D33706
llvm-svn: 305711
Summary:
If the first parameter of the function is the ImplicitParamDecl, codegen
automatically marks it as an implicit argument with `this` or `self`
pointer. Added internal kind of the ImplicitParamDecl to separate
'this', 'self', 'vtt' and other implicit parameters from other kind of
parameters.
Reviewers: rjmccall, aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33735
llvm-svn: 305075
This patch provides a means to specify section-names for global variables,
functions and static variables, using #pragma directives.
This feature is only defined to work sensibly for ELF targets.
One can specify section names as:
#pragma clang section bss="myBSS" data="myData" rodata="myRodata" text="myText"
One can "unspecify" a section name with empty string e.g.
#pragma clang section bss="" data="" text="" rodata=""
Reviewers: Roger Ferrer, Jonathan Roelofs, Reid Kleckner
Differential Revision: https://reviews.llvm.org/D33412
llvm-svn: 304705
__unaligned is not currently mangled in any way in the Itanium ABI. This causes
failures when using -fms-extensions and C++ in targets using Itanium ABI.
As suggested by @rsmith the simplest thing to do here is actually mangle the
qualifier as a vendor extension.
This patch also removes the change done in D31976 and updates its test to the
new reality.
This fixes
https://bugs.llvm.org/show_bug.cgi?id=33080https://bugs.llvm.org/show_bug.cgi?id=33178
Differential Revision: https://reviews.llvm.org/D33398
llvm-svn: 304523
Summary:
We need to emit barrier if the union field
is CXXRecordDecl because it might have vptrs. The testcode
was wrongly devirtualized. It also proves that having different
groups for different dynamic types is not sufficient.
Reviewers: rjmccall, rsmith, mehdi_amini
Subscribers: amharc, cfe-commits
Differential Revision: https://reviews.llvm.org/D31830
llvm-svn: 304448
Summary:
We can emit vtable definition having inline function
if they are all emitted.
Reviewers: rjmccall, rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33437
llvm-svn: 304394
Credit goes to Gor Nishanov for putting together the fix in
https://reviews.llvm.org/D33733!
This patch is essentially me patching it locally and writing some test
cases to convince myself that it was necessary for GNU statement
expressions with branches as well as coroutines. I'll ask Gor to land
his patch with just the coroutines test.
During LValue expression evaluation, references can be bound to
anything, really: call results, aggregate temporaries, local variables,
global variables, or indirect arguments. We really only want to spill
instructions that were emitted as part of expression evaluation, and
static allocas are not that.
llvm-svn: 304335
Amongst other, this will help LTO to correctly handle/honor files
compiled with O0, helping debugging failures.
It also seems in line with how we handle other options, like how
-fnoinline adds the appropriate attribute as well.
Differential Revision: https://reviews.llvm.org/D28404
llvm-svn: 304127
Re-commit r303463 now that LLVM is fixed and adjust some lit tests.
llvm::TargetLibraryInfo needs to know the size of wchar_t to work on
functions like `wcslen`. This patch changes clang to always emit the
wchar_size module flag (it would only do so for ARM previously).
This also adds an `assert()` to ensure the LLVM defaults based on the
target triple are in sync with clang.
Differential Revision: https://reviews.llvm.org/D32982
llvm-svn: 303478
Alloca always returns a pointer in alloca address space, which may
be different from the type defined by the language. For example,
in C++ the auto variables are in the default address space. Therefore
cast alloca to the expected address space when necessary.
Differential Revision: https://reviews.llvm.org/D32248
llvm-svn: 303370
This fixes a regression introduced in r302915.
Using the lexical decl context is not necessary here for what r302915
wast trying to achieve. Not canonicalizing the NamespaceDecl in
getOrCreateNamespace is suficient.
rdar://problem/29339538
llvm-svn: 303222
https://bugs.llvm.org/show_bug.cgi?id=32933
Turns out clang wasn't really handling vla's (*) in C++11's for-range entirely correctly.
For e.g. This would lead to generation of buggy IR:
void foo(int b) {
int vla[b];
b = -1; // This store would affect the '__end = vla + b'
for (int &c : vla)
c = 0;
}
Additionally, code-gen would get confused when VLA's were reference-captured by lambdas, and then used in a for-range, which would result in an attempt to generate IR for '__end = vla + b' within the lambda's body - without any capture of 'b' - hence the assertion.
This patch modifies clang, so that for VLA's it translates the end pointer approximately into:
__end = __begin + sizeof(vla)/sizeof(vla->getElementType())
As opposed to the __end = __begin + b;
I considered passing a magic value into codegen - or having codegen special case the '__end' variable when it referred to a variably-modified type, but I decided against that approach, because it smelled like I would be increasing a complicated form of coupling, that I think would be even harder to maintain than the above approach (which can easily be optimized (-O1) to refer to the run-time bound that was calculated upon array's creation or copied into the lambda's closure object).
(*) why oh why gcc would you enable this by default?! ;)
llvm-svn: 303026
It's failing due to Hexagon calling convention lowering being broken (empty
structs are not passed even if they have nontrivial destructors / copy ctors).
llvm-svn: 302825
in list-initialization, run cleanups for the default argument after each
iteration of the initialization loop.
We previously only ran the destructor for any temporary once, at the end of the
complete loop, rather than once per iteration!
Re-commit of r302750, reverted in r302776.
llvm-svn: 302817
Revert "clang/test/CodeGenCXX/array-default-argument.cpp: Satisfy targets that have x86_thiscallcc."
This reverts commit r302750 and its fixup r302757 because the test is
still breaking on some of the ARM bots.
array-default-argument.cpp:20:12: error: expected string not found in input
// CHECK: {{call|invoke}}[[THISCALL:( x86_thiscallcc)?]] void @_ZN1AC1Ev([[TEMPORARY:.*]])
^
<stdin>:18:1: note: scanning from here
arrayctor.loop: ; preds = %arrayctor.loop, %entry
^
<stdin>:28:2: note: possible intended match here
call void @_Z1fv()
^
--
llvm-svn: 302776
in list-initialization, run cleanups for the default argument after each
iteration of the initialization loop.
We previously only ran the destructor for any temporary once, at the end of the
complete loop, rather than once per iteration!
llvm-svn: 302750
This avoids problems on code like this:
char buf[16];
__asm {
movups xmm0, [buf]
mov [buf], eax
}
The frontend size in this case (1) is wrong, and the register makes the
instruction matching unambiguous. There are also enough bytes available
that we shouldn't complain to the user that they are potentially using
an incorrectly sized instruction to access the variable.
Supersedes D32636 and D26586 and fixes PR28266
llvm-svn: 302179
Fix the nullability-assign check so that it can handle assignments into
C++ structs. Previously, such assignments were not instrumented.
Testing: check-clang, check-ubsan, enabling the existing test in ObjC++
mode, and building some Apple frameworks with -fsanitize=nullability.
llvm-svn: 301482
It's possible to determine the alignment of an alloca at compile-time.
Use this information to skip emitting some runtime alignment checks.
Testing: check-clang, check-ubsan.
This significantly reduces the amount of alignment checks we emit when
compiling X86ISelLowering.cpp. Here are the numbers from patched/unpatched
clangs based on r301361.
------------------------------------------
| Setup | # of alignment checks |
------------------------------------------
| unpatched, -O0 | 47195 |
| patched, -O0 | 30876 | (-34.6%)
------------------------------------------
llvm-svn: 301377
This switches from the prototype syntax in P0273R0 ('module' and 'module
implementation') to the consensus syntax 'export module' and 'module'.
In passing, drop the "module declaration must be first" enforcement, since EWG
seems to have changed its mind on that.
llvm-svn: 301056
Windows Itanium aims to use MSVC export and import semantics. Inner
class members shouldn't be exported on a dllexport explicit
instantiation definition of the outer class, and they shouldn't be
imported on a dllimport explicit instantiation declaration of the outer
class (instead a local copy should be emitted). We were doing the first
but not the second, and this mismatch can lead to link errors. Fix the
behavior and add tests for both.
Differential Revision: https://reviews.llvm.org/D32213
llvm-svn: 300804
Under -fms-extensions __unaligned is a type-qualifier that can be applied to a
non-static member function declaration.
This causes an assertion when mangling the name under Itanium, where that
qualifier is not mangled.
This patch justs makes the minimal change to avoid the crash and avoid mangling
__unaligned, as it currently happens with non-member functions.
Differential Revision: https://reviews.llvm.org/D31976
llvm-svn: 300686
LLVM has changed the semantics of dbg.declare for describing function
arguments. After this patch a dbg.declare always takes the *address*
of a variable as the first argument, even if the argument is not an
alloca.
https://bugs.llvm.org/show_bug.cgi?id=32382
rdar://problem/31205000
llvm-svn: 300523
The IR builder can constant-fold null checks if the pointer operand
points to a constant. If the "is-non-null" check is folded away to
"true", don't emit the null check + branch.
Testing: check-clang, check-ubsan.
This slightly reduces the amount of null checks we emit when compiling
X86ISelLowering.cpp. Here are the numbers from patched/unpatched clangs
based on r300371.
-------------------------------------
| Setup | # of null checks |
-------------------------------------
| unpatched, -O0 | 25251 |
| patched, -O0 | 23925 | (-5.3%)
-------------------------------------
llvm-svn: 300509
Pointers to the start of an alloca are non-null, so we don't need to
emit runtime null checks for them.
Testing: check-clang, check-ubsan.
This significantly reduces the amount of null checks we emit when
compiling X86ISelLowering.cpp. Here are the numbers from patched /
unpatched clangs based on r300371.
-------------------------------------
| Setup | # of null checks |
-------------------------------------
| unpatched, -O0 | 45439 |
| patched, -O0 | 25251 | (-44.4%)
-------------------------------------
llvm-svn: 300508
If a pointer is 1-byte aligned, there's no use in checking its
alignment. Somewhat surprisingly, ubsan can spend a significant amount
of time doing just that!
This loosely depends on D30283.
Testing: check-clang, check-ubsan, and a stage2 ubsan build.
Differential Revision: https://reviews.llvm.org/D30285
llvm-svn: 300371
This patch teaches ubsan to insert an alignment check for the 'this'
pointer at the start of each method/lambda. This allows clang to emit
significantly fewer alignment checks overall, because if 'this' is
aligned, so are its fields.
This is essentially the same thing r295515 does, but for the alignment
check instead of the null check. One difference is that we keep the
alignment checks on member expressions where the base is a DeclRefExpr.
There's an opportunity to diagnose unaligned accesses in this situation
(as pointed out by Eli, see PR32630).
Testing: check-clang, check-ubsan, and a stage2 ubsan build.
Along with the patch from D30285, this roughly halves the amount of
alignment checks we emit when compiling X86FastISel.cpp. Here are the
numbers from patched/unpatched clangs based on r298160.
------------------------------------------
| Setup | # of alignment checks |
------------------------------------------
| unpatched, -O0 | 24326 |
| patched, -O0 | 12717 | (-47.7%)
------------------------------------------
Differential Revision: https://reviews.llvm.org/D30283
llvm-svn: 300370
Setting dllexport on a declaration has no effect, as we do not emit export
directives for declarations.
Part of the fix for PR32334.
Differential Revision: https://reviews.llvm.org/D31162
llvm-svn: 298330
It's possible to load out-of-range values from bitfields backed by a
boolean or an enum. Check for UB loads from bitfields.
This is the motivating example:
struct S {
BOOL b : 1; // Signed ObjC BOOL.
};
S s;
s.b = 1; // This is actually stored as -1.
if (s.b == 1) // Evaluates to false, -1 != 1.
...
Changes since the original commit:
- Single-bit bools are a special case (see CGF::EmitFromMemory), and we
can't avoid dealing with them when loading from a bitfield. Don't try to
insert a check in this case.
Differential Revision: https://reviews.llvm.org/D30423
llvm-svn: 297389
It's possible to load out-of-range values from bitfields backed by a
boolean or an enum. Check for UB loads from bitfields.
This is the motivating example:
struct S {
BOOL b : 1; // Signed ObjC BOOL.
};
S s;
s.b = 1; // This is actually stored as -1.
if (s.b == 1) // Evaluates to false, -1 != 1.
...
Differential Revision: https://reviews.llvm.org/D30423
llvm-svn: 297298
This patch honors the unaligned type qualifier (currently available through he
keyword __unaligned and -fms-extensions) in CodeGen. In the current form the
patch affects declarations and expressions. It does not affect fields of
classes.
Differential Revision: https://reviews.llvm.org/D30166
llvm-svn: 297276
Summary:
Because of the existence branches out of GNU statement expressions, it
is possible that emitting cleanups for a full expression may cause the
new insertion point to not be dominated by the result of the inner
expression. Consider this example:
struct Foo { Foo(); ~Foo(); int x; };
int g(Foo, int);
int f(bool cond) {
int n = g(Foo(), ({ if (cond) return 0; 42; }));
return n;
}
Before this change, result of the call to 'g' did not dominate its use
in the store to 'n'. The early return exit from the statement expression
branches to a shared cleanup block, which ends in a switch between the
fallthrough destination (the assignment to 'n') or the function exit
block.
This change solves the problem by spilling and reloading expression
evaluation results when any of the active cleanups have branches.
I audited the other call sites of enterFullExpression, and they don't
appear to keep and Values live across the site of the cleanup, except in
ARC code. I wasn't able to create a test case for ARC that exhibits this
problem, though.
Reviewers: rjmccall, rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D30590
llvm-svn: 297084
When clang emits an inheriting C++ constructor it may inline code
during the CodeGen phase. This patch ensures that any debug info in
this inlined code gets a proper inlined location. Otherwise we can end
up with invalid debug info metadata, since all inlined local variables
and function arguments would be reparented into the call site.
Analogous to ApplyInlineLocation this patch introduces a
ApplyInlineDebugLocation scoped helper to facilitate entering an
inlined scope and cleaning up afterwards.
This fixes one of the issues discovered in PR32042.
rdar://problem/30679307
llvm-svn: 296388
Essentially, as a base class constructor does not construct virtual bases, such
a constructor for an abstract class does not need the corresponding base class
construction to be valid, and likewise for destructors.
This creates an awkward situation: clang will sometimes generate references to
the complete object and deleting destructors for an abstract class (it puts
them in the construction vtable for a derived class). But we can't generate a
"correct" version of these because we can't generate references to base class
constructors any more (if they're template specializations, say, we might not
have instantiated them and can't assume any other TU will emit a copy).
Fortunately, we don't need to, since no correct program can ever invoke them,
so instead emit symbols that just trap.
We should stop emitting references to these symbols, but still need to emit
definitions for compatibility.
llvm-svn: 296275
Summary: We implement structured exception handling (SEH) by generating filter functions for functions that use exceptions. Currently, we use associative comdats to ensure that the filter functions are preserved if and only if the functions we generated them for are preserved. This can lead to problems when generating COFF objects - LLVM may decide to inline a function that uses SEH and remove its body, at which point we will end up with a comdat that COFF cannot represent. To avoid running into that situation, this change makes us not use associative comdats for SEH filter functions. We can still get the benefits we used the associative comdats for: we will always preserve filter functions we use, and dead stripping can eliminate the ones we don't use.
Reviewers: rnk, pcc, ruiu
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D30117
llvm-svn: 295872
declaration declared using class template argument deduction.
Patch by Eric Fiselier (who is busy and asked me to commit this on his behalf)!
Differential Revision: https://reviews.llvm.org/D30082
llvm-svn: 295794
This patch teaches ubsan to insert exactly one null check for the 'this'
pointer per method/lambda.
Previously, given a load of a member variable from an instance method
('this->x'), ubsan would insert a null check for 'this', and another
null check for '&this->x', before allowing the load to occur.
Similarly, given a call to a method from another method bound to the
same instance ('this->foo()'), ubsan would a redundant null check for
'this'. There is also a redundant null check in the case where the
object pointer is a reference ('Ref.foo()').
This patch teaches ubsan to remove the redundant null checks identified
above.
Testing: check-clang, check-ubsan, and a stage2 ubsan build.
I also compiled X86FastISel.cpp with -fsanitize=null using
patched/unpatched clangs based on r293572. Here are the number of null
checks emitted:
-------------------------------------
| Setup | # of null checks |
-------------------------------------
| unpatched, -O0 | 21767 |
| patched, -O0 | 10758 |
-------------------------------------
Changes since the initial commit:
- Don't introduce any unintentional object-size or alignment checks.
- Don't rely on IRGen of C labels in the test.
Differential Revision: https://reviews.llvm.org/D29530
llvm-svn: 295515
This reverts commit r295401. It breaks the ubsan self-host. It inserts
object size checks once per C++ method which fire when the structure is
empty.
llvm-svn: 295494
This patch teaches ubsan to insert exactly one null check for the 'this'
pointer per method/lambda.
Previously, given a load of a member variable from an instance method
('this->x'), ubsan would insert a null check for 'this', and another
null check for '&this->x', before allowing the load to occur.
Similarly, given a call to a method from another method bound to the
same instance ('this->foo()'), ubsan would a redundant null check for
'this'. There is also a redundant null check in the case where the
object pointer is a reference ('Ref.foo()').
This patch teaches ubsan to remove the redundant null checks identified
above.
Testing: check-clang and check-ubsan. I also compiled X86FastISel.cpp
with -fsanitize=null using patched/unpatched clangs based on r293572.
Here are the number of null checks emitted:
-------------------------------------
| Setup | # of null checks |
-------------------------------------
| unpatched, -O0 | 21767 |
| patched, -O0 | 10758 |
-------------------------------------
Changes since the initial commit: don't rely on IRGen of C labels in the
test.
Differential Revision: https://reviews.llvm.org/D29530
llvm-svn: 295401
This patch teaches ubsan to insert exactly one null check for the 'this'
pointer per method/lambda.
Previously, given a load of a member variable from an instance method
('this->x'), ubsan would insert a null check for 'this', and another
null check for '&this->x', before allowing the load to occur.
Similarly, given a call to a method from another method bound to the
same instance ('this->foo()'), ubsan would a redundant null check for
'this'. There is also a redundant null check in the case where the
object pointer is a reference ('Ref.foo()').
This patch teaches ubsan to remove the redundant null checks identified
above.
Testing: check-clang and check-ubsan. I also compiled X86FastISel.cpp
with -fsanitize=null using patched/unpatched clangs based on r293572.
Here are the number of null checks emitted:
-------------------------------------
| Setup | # of null checks |
-------------------------------------
| unpatched, -O0 | 21767 |
| patched, -O0 | 10758 |
-------------------------------------
Differential Revision: https://reviews.llvm.org/D29530
llvm-svn: 295391
Destructor references are not modelled explicitly in the AST. This adds
checks for destructor calls due to variable definitions and temporaries.
If a dllimport function references a non-dllimport destructor, it must
not be emitted available_externally, as the referenced destructor might
live across the DLL boundary and isn't exported.
llvm-svn: 295258
The function is used to check whether a type is a class with
non-dllimport destructor. It needs to look through typedefs and array
types.
llvm-svn: 295257
They are a little bit of a special case in the mangling. They are always
mangled without taking into account their virtual-ness of the
destructor. They are also mangled to return void, unlike the actual
destructor.
This fixes PR31931.
Differential Revision: https://reviews.llvm.org/D29912
llvm-svn: 295010
This bypasses integer sanitization checks which are redundant on the expression since it's been checked by Sema. Fixes a clang codegen assertion on "void test() { new int[0+1]{0}; }" when building with -fsanitize=signed-integer-overflow.
llvm-svn: 295006
Sometimes the MS ABI needs to emit thunks for declarations that don't
have bodies. Destructor thunks make calls to inlinable functions, so
they need line info or LLVM will complain.
Fixes PR31893
llvm-svn: 294465
Guard against a null pointer dereference that caused Clang to crash
when processing a class containing an _Atomic qualified data member,
and that is tagged with 'dllexport'.
Differential Revision: https://reviews.llvm.org/D29208
llvm-svn: 293911
For non-template dllimport functions, MSVC allows providing an inline
definition without spelling out the attribute again. In the example below, f
remains a dllimport function.
__declspec(dllimport) int f();
inline int f() { return 42; }
int useit() {
return f();
}
However, for a function template, not putting dllimport on the redeclaration
causes it to be dropped. In the example below, f is not dllimport.
template <typename> __declspec(dllimport) int f();
template <typename> inline int f() { return 42; }
int useit() {
return f<int>();
}
This patch makes Clang match MSVC for the second example.
MSVC does not warn about the attribute being dropped in the example above, but
I think we should. (MSVC does warn if the inline keyword isn't used.)
Differential Revision: https://reviews.llvm.org/D29152
llvm-svn: 293800
clang-cl would evaluate the arguments right-to-left (see PR), and for
non-Windows targets I suppose we only got it because we were already
emitting left-to-right in CodeGenFunction::EmitCallArgs.
Differential Revision: https://reviews.llvm.org/D29350
llvm-svn: 293732
The Module::WithCodegen flag was only being set when the module was
parsed from a ModuleMap. Instead set it late, in the ASTWriter to match
the layer where the MODULAR_CODEGEN_DECLs list is determined (the
WithCodegen flag essentially means "are this module's decls in
MODULAR_CODEGEN_DECLs").
When simultaneous emission of AST file and modular object is implemented
this may need to change - the Module::WithCodegen flag will need to be
set earlier, and ideally the MODULAR_CODEGEN_DECLs gathering will
consult this flag (that's not possible right now since Decls destined
for an AST File don't have a Module - only if they're /read/ from a
Module is that true - I expect that would need to change as well).
llvm-svn: 293692
Accounts for a case that caused an assertion failure by attempting to
query for the vtable linkage of a non-dynamic type.t
This reverts commit r292801.
llvm-svn: 293462
As Mehdi put it, entities should either be
available_externally+weak_odr, or linkonce_odr+linkonce_odr. While some
functions are emitted a_e/weak, their local variables were emitted
a_e/linkonce_odr.
While it might be nice to emit them a_e/weak, the Itanium ABI (& best
guess at MSVC's behavior as well) requires the local to be
linkonce/linkonce.
Reviewers: rsmith, mehdi_amini
Differential Revision: https://reviews.llvm.org/D29233
llvm-svn: 293344
Summary:
This reverts commit r292662.
This change broke internal builds. Will provide a reproducer internally.
Subscribers: pcc, mehdi_amini, cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D29025
llvm-svn: 292791
To ensure optimization level doesn't pessimize the -fstandalone-debug
vtable debug info optimization (where class definitions are only emitted
where the vtable is emitted - reducing redundant debug info) ensure the
debug info class definition is still omitted when an
available_externally vtable definition is emitted for optimization
purposes.
llvm-svn: 292768
by providing a memchr builtin that returns char* instead of void*.
Also add a __has_feature flag to indicate the presence of constexpr forms of
the relevant <string> functions.
llvm-svn: 292555
In ThinLTO mode, type metadata will require the module to be written as a
multi-module bitcode file, which is currently incompatible with the Darwin
linker. It is also useful to be able to enable or disable multi-module bitcode
for testing purposes. This introduces a cc1-level flag, -f{,no-}lto-unit,
which is used by the driver to enable multi-module bitcode on all but
Darwin+ThinLTO, and can also be used to enable/disable the feature manually.
Differential Revision: https://reviews.llvm.org/D28877
llvm-svn: 292448
Using the canonical type instead of the equivalent type can result in
insufficient template instantiations.
This fixes PR31656.
Differential Revision: https://reviews.llvm.org/D28788
llvm-svn: 292194
This comes up in V8, which has a Handle template class that wraps a
typed pointer, and is frequently passed by value. The pointer is stored
in the base, HandleBase. This change allows us to pass the struct as a
pointer instead of using byval. This avoids creating tons of temporary
allocas that we copy from during call lowering.
Eventually, it would be good to use FCAs here instead.
llvm-svn: 291917
In the case where the template class itself is already `dllexport`, the
implicit instantiation will have already emitted all members. When we
check the explicit instantiation definition, the `Specialization` will
have inherited the `dllexport` attribute, so we'll attempt to emit all
members for a second time, which causes an assertion failure. Restrict
the exporting to when the `dllexport` attribute is newly introduced by
the explicit instantiation definition.
Fixes PR31608.
Differential Revision: https://reviews.llvm.org/D28590
llvm-svn: 291877
* Do not initialize these variables when initializing the rest of the
thread_locals in the TU; they have unordered initialization so they can be
initialized by themselves.
This fixes a rejects-valid bug: we would make the per-variable initializer
function internal, but put it in a comdat keyed off the variable, resulting
in link errors when the comdat is selected from a different TU (as the per
TU TLS init function tries to call an init function that does not exist).
* On Darwin, when we decide that we're not going to emit a thread wrapper
function at all, demote its linkage to External. Fixes a verifier failure
on explicit instantiation of a thread_local variable on Darwin.
llvm-svn: 291865
Fix crash if __FUNCSIG__ is used in a function without a prototype, and use
"(void)" as parameter list instead of "()" for a function with a no-parameters
prototype, matching MSVC's observed behavior.
llvm-svn: 291484
Summary:
Per https://wg21.link/CWG1677, the C++11 standard did not clarify that constant
initialization of an object allowed constexpr brace-or-equal initialization of
subobjects:
struct foo_t { union { int i; volatile int j; } u; };
__attribute__((__require_constant_initialization__))
static const foo_t x = {{0}};
Because foo_t::u has a volatile member, the initializer for x fails. However,
there is really no good reason, because this:
union foo_u { int i; volatile int j; };
__attribute__((__require_constant_initialization__))
static const foo_u x = {0};
does have a constant initializer.
(This was triggered by musl's pthread_mutex_t type when building under C++11.)
Reviewers: rsmith
Subscribers: EricWF, cfe-commits
Differential Revision: https://reviews.llvm.org/D28427
llvm-svn: 291480
In C++11, a destructor's implicit exception-spec is nothrow.
The IR for the destructor's invocation changed from invoke to call.
Differential Revision: https://reviews.llvm.org/D28425
llvm-svn: 291458
Fixes a regression introduced in r291045, which would lead to link
errors. While we should no longer encounter unparsed or uninstantiated
default arguments in this codepath, we still need to call
CheckCXXDefaultArgExpr to mark the default argument expressions as
ODR-used.
llvm-svn: 291453
Use the canonical decl in pointer comparisons with the default
constructor closure decl. Otherwise we don't produce the correct
"@@QAEXXZ" mangling, which essentially means "void(void) thiscall public
instance method".
llvm-svn: 291448
Summary:
This patch makes the type_mismatch static data 7 bytes smaller (and it
ends up being 16 bytes smaller due to alignment restrictions, at least
on some x86-64 environments).
It revs up the type_mismatch handler version since we're breaking binary
compatibility. I will soon post a patch for the compiler-rt side.
Reviewers: rsmith, kcc, vitalybuka, pgousseau, gbedwell
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28242
llvm-svn: 291236
Summary:
Replace some old code that probably pre-dated the change to delay
emission of dllexported code until after the closing brace of the
outermost record type. Only uninstantiated default argument expressions
need to be handled now. It is enough to instantiate default argument
expressions when instantiating dllexported default ctors. This also
fixes some double-diagnostic issues in this area.
Fixes PR31500
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28274
llvm-svn: 291045
Front end component (back end changes are D27392). The vectorcall
calling convention was broken subtly in two cases. First,
it didn't properly handle homogeneous vector aggregates (HVAs).
Second, the vectorcall specification requires that only the
first 6 parameters be eligible for register assignment.
This patch fixes both issues.
Differential Revision: https://reviews.llvm.org/D27529
llvm-svn: 291041
in non-void functions that fall off at the end without returning a value when
compiling C++.
Clang uses the new compiler flag to determine when it should treat control flow
paths that fall off the end of a non-void function as unreachable. If
-fno-strict-return is on, the code generator emits the ureachable and trap
IR only when the function returns either a record type with a non-trivial
destructor or another non-trivially copyable type.
The primary goal of this flag is to avoid treating falling off the end of a
non-void function as undefined behaviour. The burden of undefined behaviour
is placed on the caller instead: if the caller ignores the returned value then
the undefined behaviour is avoided. This kind of behaviour is useful in
several cases, e.g. when compiling C code in C++ mode.
rdar://13102603
Differential Revision: https://reviews.llvm.org/D27163
llvm-svn: 290960
This seems like it must've been a leftover by accident - no tests were
backing it up & it doesn't make much sense to include size/alignment on
class declarations (it'd only be on those declarations for which the
definition was available - otherwise the size/alignment would not be
known).
llvm-svn: 290631
-fno-inline-functions, -O0, and optnone.
These were really, really tangled together:
- We used the noinline LLVM attribute for -fno-inline
- But not for -fno-inline-functions (breaking LTO)
- But we did use it for -finline-hint-functions (yay, LTO is happy!)
- But we didn't for -O0 (LTO is sad yet again...)
- We had weird structuring of CodeGenOpts with both an inlining
enumeration and a boolean. They interacted in weird ways and
needlessly.
- A *lot* of set smashing went on with setting these, and then got worse
when we considered optnone and other inlining-effecting attributes.
- A bunch of inline affecting attributes were managed in a completely
different place from -fno-inline.
- Even with -fno-inline we failed to put the LLVM noinline attribute
onto many generated function definitions because they didn't show up
as AST-level functions.
- If you passed -O0 but -finline-functions we would run the normal
inliner pass in LLVM despite it being in the O0 pipeline, which really
doesn't make much sense.
- Lastly, we used things like '-fno-inline' to manipulate the pass
pipeline which forced the pass pipeline to be much more
parameterizable than it really needs to be. Instead we can *just* use
the optimization level to select a pipeline and control the rest via
attributes.
Sadly, this causes a bunch of churn in tests because we don't run the
optimizer in the tests and check the contents of attribute sets. It
would be awesome if attribute sets were a bit more FileCheck friendly,
but oh well.
I think this is a significant improvement and should remove the semantic
need to change what inliner pass we run in order to comply with the
requested inlining semantics by relying completely on attributes. It
also cleans up tho optnone and related handling a bit.
One unfortunate aspect of this is that for generating alwaysinline
routines like those in OpenMP we end up removing noinline and then
adding alwaysinline. I tried a bunch of other approaches, but because we
recompute function attributes from scratch and don't have a declaration
here I couldn't find anything substantially cleaner than this.
Differential Revision: https://reviews.llvm.org/D28053
llvm-svn: 290398
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
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
effect they would have in C++11. In particular, they do not prevent
value-initialization from performing zero-initialization, nor do they prevent a
struct from being an aggregate.
llvm-svn: 290229
In stack-reuse-miscompile.cpp, the allocas for the temps come out in
a different order depending on whether the dialect is C++03 or
C++11. Specify C++03 explicitly to avoid depending on the default.
Differential Revision: http://reviews.llvm.org/D27956
llvm-svn: 290208
If a dtor has no interesting members, then it ends up being nothrow,
which affects the generated IR. Modify some tests to tolerate this
difference between C++03 and C++11.
Differential Revision: http://reviews.llvm.org/D27936
llvm-svn: 290207
In C++11 we don't emit vtables as eagerly as we do for C++03, so
fiddle the tests to emit them when the test expects them.
Differential Revision: http://reviews.llvm.org/D27994
llvm-svn: 290205
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
Ilya Biryukov