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
Properly attribute DLL storage to runtime functions. When generating the
runtime function, scan for an existing declaration which may provide an explicit
declaration (local storage) or a DLL import or export storage from the user.
Honour that if available. Otherwise, if building with a local visibility of the
public or standard namespaces (-flto-visibility-public-std), give the symbols
local storage (it indicates a /MT[d] link, so static runtime). Otherwise,
assume that the link is dynamic, and give the runtime function dllimport
storage.
This allows for implementations to get the correct storage as long as they are
properly declared, the user to override the import storage, and in case no
explicit storage is given, use of the import storage.
llvm-svn: 289776
copy constructors of classes with array members, instead using
ArrayInitLoopExpr to represent the initialization loop.
This exposed a bug in the static analyzer where it was unable to differentiate
between zero-initialized and unknown array values, which has also been fixed
here.
llvm-svn: 289618
This annotation allows the optimizer to split vtable groups, as permitted by
a change to the Itanium ABI [1] that prevents compilers from adjusting virtual
table pointers between virtual tables.
[1] https://github.com/MentorEmbedded/cxx-abi/pull/7
Differential Revision: https://reviews.llvm.org/D24431
llvm-svn: 289585
In a future change, this representation will allow us to use the new inrange
annotation on getelementptr to allow the optimizer to split vtable groups.
Differential Revision: https://reviews.llvm.org/D22296
llvm-svn: 289584
We continue to support dynamic exception specifications in C++1z as an
extension, but produce an error-by-default warning when we encounter one. This
allows users to opt back into the feature with a warning flag, and implicitly
opts system headers back into the feature should they happen to use it.
There is one semantic change implied by P0003R5 but not implemented here:
violating a throw() exception specification should now call std::terminate
directly instead of calling std::unexpected(), but since P0003R5 also removes
std::unexpected() and std::set_unexpected, and the default unexpected handler
calls std::terminate(), a conforming C++1z program cannot tell that we are
still calling it. The upside of this strategy is perfect backwards
compatibility; the downside is that we don't get the more efficient 'noexcept'
codegen for 'throw()'.
llvm-svn: 289019
The problem only happen on window ( A MS-ABI issuer )
The nature of the problem is virtual base dtor called more than it is needed after exception throw in inheriting base class(with virtual bases) ctor.
The root problem is when throw happen, not all virtual base classes have been contructed, so not all virtual base dtors are need to call for ehcleanup.
clang has code to handle vbase initialization: basically add check for "complete object flag" before call to v-base ctor.
But that part is missing for cleanup code.
To fix this add similar code as v-base init to cleanup code, same algorithm.
1> Add new routine:
EmitDtorCompleteObjectHandler
With corresponding to EmitCtorCompleteObjectHandler
2> In the EmitDestructorCal
Call EmitDtorCompleteObjectHandler when generate ehcleanup inside ctor.
Just add check for "complete object flag" before call to v-base dtor.
Without my change:
ehcleanup: ; preds = %ctor.skip_vbases
%13 = cleanuppad within none [], !dbg !66
%14 = bitcast %struct.class_0* %this1 to i8*, !dbg !66
%15 = getelementptr inbounds i8, i8* %14, i64 8, !dbg !66
%16 = bitcast i8* %15 to %struct.class_2*, !dbg !66
call void @"\01??1class_2@@UEAA@XZ"(%struct.class_2* %16) #6 [ "funclet"(token
%13) ], !dbg !66
cleanupret from %13 unwind to caller, !dbg !66
with my change:
ehcleanup: ; preds = %ctor.skip_vbases
%13 = cleanuppad within none [], !dbg !66
%14 = bitcast %struct.class_0* %this1 to i8*, !dbg !66
%15 = getelementptr inbounds i8, i8* %14, i64 8, !dbg !66
%16 = bitcast i8* %15 to %struct.class_2*, !dbg !66
%is_complete_object4 = icmp ne i32 %is_most_derived2, 0, !dbg !66
br i1 %is_complete_object4, label %Dtor.dtor_vbase, label %Dtor.skip_vbase, !d
bg !66
Dtor.dtor_vbase: ; preds = %ehcleanup
call void @"\01??1class_2@@UEAA@XZ"(%struct.class_2* %16) #6 [ "funclet"(token
%13) ], !dbg !66
br label %Dtor.skip_vbase, !dbg !66
Dtor.skip_vbase: ; preds = %Dtor.dtor_vbase, %ehcleanup
cleanupret from %13 unwind to caller, !dbg !66
Please let me know you need more info.
Patch by Jennifer Yu.
Differential Revision: https://reviews.llvm.org/D27358
llvm-svn: 288869
When an object of class type is initialized from a prvalue of the same type
(ignoring cv qualifications), use the prvalue to initialize the object directly
instead of inserting a redundant elidable call to a copy constructor.
llvm-svn: 288866
We didn't implement handle corner cases like:
- lambdas used to initialize a field
- lambdas in default argument initializers
This fixes PR31197.
Differential Revision: https://reviews.llvm.org/D27226
llvm-svn: 288826
When emitting RTTI for EH only, we would mark the locally defined (LinkOnceODR)
RTTI definition as dllimport, which is incorrect. Ensure that if we are
generating the type information for EH only, it is marked as LinkOnceODR and we
do not make it dllimport.
llvm-svn: 288721
On MSVC, if an implicit instantiation already exists and an explicit
instantiation definition with a DLL attribute is created, the DLL
attribute still takes effect. Make clang match this behavior for
exporting.
Differential Revision: https://reviews.llvm.org/D26657
llvm-svn: 288682
latter case, a temporary array object is materialized, and can be
lifetime-extended by binding a reference to the member access. Likewise, in an
array-to-pointer decay, an rvalue array is materialized before being converted
into a pointer.
This caused IR generation to stop treating file-scope array compound literals
as having static storage duration in some cases in C++; that has been rectified
by modeling such a compound literal as an lvalue. This also improves clang's
compatibility with GCC for those cases.
llvm-svn: 288654
An explicit template specialization can cause the implicit template
specialization of a type which inherits the attributes. In such a case, we
would end up with a delayed template specialization for a dll exported type
which we would fail to reference. This would trigger an assertion.
We now propagate the dll storage attributes through the inheritance
chain. Only after having done so do we reference the delayed template
specializations. This allows any implicit specializations which inherit dll
storage to also be referenced.
llvm-svn: 288570
When a C++ record is marked with dllexport mark both the typeinfo and the
typeinfo name as being exported. Handle dllimport as the inverse. This applies
to the itanium environment and not the MinGW environment.
llvm-svn: 288546
have the same size.
This fixes an asset that is triggered when an address of a boolean
variable is passed to __builtin_arm_ldrex or __builtin_arm_strex.
rdar://problem/29269006
llvm-svn: 288404
This is needed because whether the constructor is deleted can control whether
we pass structs by value directly.
To fix this properly we probably want a more direct way for CodeGen to ask
whether the constructor was deleted.
Fixes PR31049.
Differential Revision: https://reviews.llvm.org/D26822
llvm-svn: 287600
Summary:
this is to prevent a situation when a pointer is invalid or null,
but we get to reading from vtable before we can check that
(possibly causing a segfault without a good diagnostics).
Reviewers: pcc
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D26559
llvm-svn: 287181
Instead of always displaying the mangled name, try to do better
and get something closer to regular functions.
Recommit r287039 (that was reverted in r287039) with a tweak to
be more generic, and test fixes!
Differential Revision: https://reviews.llvm.org/D26522
llvm-svn: 287085
Instead of always displaying the mangled name, try to do better
and get something closer to regular functions.
Differential Revision: https://reviews.llvm.org/D26522
llvm-svn: 287039
Clang emits error message for the following code:
```
template <class F> void parallel_loop(F &&f) { f(0); }
int main() {
int x;
parallel_loop([&](auto y) {
{
x = y;
};
});
}
```
$ clang++ --std=gnu++14 clang_test.cc -o clang_test
clang_test.cc:9:7: error: reference to local variable 'x' declared in enclosing function 'main'
x = y;
^
clang_test.cc:2:48: note: in instantiation of function template specialization 'main()::(anonymous class)::operator()<int>' requested here
template <class F> void parallel_loop(F &&f) { f(0); }
^
clang_test.cc:6:3: note: in instantiation of function template specialization 'parallel_loop<(lambda at clang_test.cc:6:17)>' requested here parallel_loop([&](auto y) {
^
clang_test.cc:5:7: note: 'x' declared here
int x;
^
1 error generated.
Patch fixes this issue.
llvm-svn: 286584
function. In that case, there is no requirement that the callee is actually
defined, and the code may in fact be valid and have defined behavior if the
virtual call is unreachable.
llvm-svn: 286534
can be used to improve the locations when generating remarks for loops.
Depends on the companion LLVM change r286227.
Patch by Florian Hahn.
Differential Revision: https://reviews.llvm.org/D25764
llvm-svn: 286456
Similar to r284288, make the Itanium ABI follow MS ABI dllexport
semantics in the case of an explicit instantiation declaration followed
by a dllexport explicit instantiation definition.
Differential Revision: https://reviews.llvm.org/D26471
llvm-svn: 286419
Thunks are artificial and have no corresponding source location except for the
line number on the DISubprogram, which is marked as artificial.
<rdar://problem/11941095>
llvm-svn: 286400
* if the base is produced by a series of derived-to-base conversions, check
the expression inside them when looking for an expression with a known
dynamic type
* step past MaterializeTemporaryExprs when checking for a known dynamic type
* when checking for a known dynamic type, treat all class prvalues as having
a known dynamic type after skipping all relevant rvalue subobject
adjustments
* treat callees formed by pointer-to-member access for a non-reference member
type like callees formed by member access.
llvm-svn: 285954
This patch implements the register call calling convention, which ensures
as many values as possible are passed in registers. CodeGen changes
were committed in https://reviews.llvm.org/rL284108.
Differential Revision: https://reviews.llvm.org/D25204
llvm-svn: 285849
on cxx-abi-dev (thread starting 2016-10-11). This is currently hidden behind a
cc1-only -m flag, pending discussion of how best to deal with language changes
that require use of new symbols from the ABI library.
llvm-svn: 285664
the body of a function for the purposes of computing its storage
duration and deciding whether its initializer must be constant.
There are a number of problems in our current treatment of compound
literals. C specifies that a compound literal yields an l-value
referring to an object with either static or automatic storage
duration, depending on where it was written; in the latter case,
the literal object has a lifetime tied to the enclosing scope (much
like an ObjC block), not the enclosing full-expression. To get these
semantics fully correct in our current design, we would need to
collect compound literals on the ExprWithCleanups, just like we do
with ObjC blocks; we would probably also want to identify literals
like we do with materialized temporaries. But it gets stranger;
GCC adds compound literals to C++ as an extension, but makes them
r-values, which are generally assumed to have temporary storage
duration. Ignoring destructor ordering, the difference only matters
if the object's address escapes the full-expression, which for an
r-value can only happen with reference binding (which extends
temporaries) or array-to-pointer decay (which does not). GCC then
attempts to lock down on array-to-pointer decay in ad hoc ways.
Arguably a far superior language solution for C++ (and perhaps even
array r-values in C, which can occur in other ways) would be to
propagate lifetime extension through array-to-pointer decay, so
that initializing a pointer object to a decayed r-value array
extends the lifetime of the complete object containing the array.
But this would be a major change in semantics which arguably ought
to be blessed by the committee(s).
Anyway, I'm not fixing any of that in this patch; I did try, but
it got out of hand.
Fixes rdar://28949016.
llvm-svn: 285643
Summary:
This patch was introduced one year ago, but because my google account
was disabled, I didn't get email with failing buildbot and I missed
revert of this commit. There was small but in test regex.
I am back.
Reviewers: rsmith, rengolin
Subscribers: nlewycky, rjmccall, cfe-commits
Differential Revision: https://reviews.llvm.org/D26117
llvm-svn: 285497
This has the following ABI impact:
1) Functions whose parameter or return types are non-throwing function pointer
types have different manglings in c++1z mode from prior modes. This is
necessary because c++1z permits overloading on the noexceptness of function
pointer parameter types. A warning is issued for cases that will change
manglings in c++1z mode.
2) Functions whose parameter or return types contain instantiation-dependent
exception specifications change manglings in all modes. This is necessary
to support overloading on / SFINAE in these exception specifications, which
a careful reading of the standard indicates has essentially always been
permitted.
Note that, in order to be affected by these changes, the code in question must
specify an exception specification on a function pointer/reference type that is
written syntactically within the declaration of another function. Such
declarations are very rare, and I have so far been unable to find any code
that would be affected by this. (Note that such things will probably become
more common in C++17, since it's a lot easier to get a noexcept function type
as a function parameter / return type there.)
This change does not affect the set of symbols produced by a build of clang,
libc++, or libc++abi.
llvm-svn: 285150
Summary:
Fixes PR28281.
MSVC lists indirect virtual base classes in the field list of a class.
This change makes Clang emit the information necessary for LLVM to
emit such records.
Reviewers: rnk, ruiu, zturner
Differential Revision: https://reviews.llvm.org/D25579
llvm-svn: 285132
to emit the <template-args> portion. Refactor so that mangleUnresolvedName
actually emits the entire <unresolved-name>, so this mistake is harder to make
again.
llvm-svn: 285022
If we see a virtual method call to Base::foo() but can infer that the
object is an instance of Derived, and that 'foo' is marked 'final' in
Derived, we can devirtualize the call to Derived::foo().
Differential Revision: https://reviews.llvm.org/D25813
llvm-svn: 284766
Preparation to implement DW_AT_alignment support:
- We pass non-zero align value to DIBuilder only when alignment was forced
- Modify tests to match this change
Differential Revision: https://reviews.llvm.org/D24426
llvm-svn: 284679
This bot does not produce the IR I expect -- it's missing some
'handler.dynamic_type_cache_miss:' labels. We don't need to rely on
those labels, so get rid of them in hopes of making the bot happy.
http://bb.pgr.jp/builders/cmake-clang-x86_64-linux/builds/55493
llvm-svn: 284639
ubsan reports a false positive 'invalid member call' diagnostic on the
following example (PR30478):
struct Base1 {
virtual int f1() { return 1; }
};
struct Base2 {
virtual int f1() { return 2; }
};
struct Derived2 final : Base1, Base2 {
int f1() override { return 3; }
};
int t1() {
Derived2 d;
return static_cast<Base2 *>(&d)->f1();
}
Adding the "final" attribute to a most-derived class allows clang to
devirtualize member calls into an instance of that class. We should pass
along the type info of the object pointer to avoid the FP. In this case,
that means passing along the type info for 'Derived2' instead of 'Base2'
when checking the dynamic type of static_cast<Base2 *>(&d2).
Differential Revision: https://reviews.llvm.org/D25448
llvm-svn: 284636
getClassAtVTableLocation() was calling
ASTRecordLayout::getBaseClassOffset() on a virtual base, causing an
assert.
Differential Revision: https://reviews.llvm.org/D25779
llvm-svn: 284624
Although the itanium environment uses the itanium layout for C++, treat the
dllexport semantics more similarly to the MSVC specification. This preserves
the existing behaviour for the use of the itanium ABI on non-windows-itanium
environments. Export the inline definitions too.
llvm-svn: 284288
There was a bug in the implementation of captured statements. If it has
a lambda expression in it and the same lambda expression is used outside
the captured region, clang produced an error:
```
error: definition with same mangled name as another definition
```
Here is an example:
```
struct A {
template <typename L>
void g(const L&) { }
};
template<typename T>
void f() {
{
A().g([](){});
}
A().g([](){});
}
int main() {
f<void>();
}
```
Error report:
```
main.cpp:3:10: error: definition with same mangled name as another
definition
void g(const L&) { }
^
main.cpp:3:10: note: previous definition is here
```
Patch fixes this bug.
llvm-svn: 284229
Summary: https://reviews.llvm.org/D25132 added discriminator even add -g0. This leads to test fail which is addressed in thie patch.
Reviewers: davidxl, dnovillo
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25133
llvm-svn: 283564
This commit fixes PR 30440 by initializing CXXNameMangler's FunctionTypeDepth
in the two constructors added in r274222 (The commit that caused this
regression).
rdar://28455269
Differential Revision: https://reviews.llvm.org/D24932
llvm-svn: 283428
new expression, distinguish between the case of a constant and non-constant
initializer. In the former case, if the bound is erroneous (too many
initializer elements, bound is negative, or allocated size overflows), reject,
and take the bound into account when determining whether we need to
default-construct any elements. In the remanining cases, move the logic to
check for default-constructibility of trailing elements into the initialization
code rather than inventing a bogus array bound, to cope with cases where the
number of initialized elements is not the same as the number of initializer
list elements (this can happen due to string literal initialization or brace
elision).
This also fixes rejects-valid and crash-on-valid errors when initializing a
new'd array of character type from a braced string literal.
llvm-svn: 283406
Reapplying the patch after modifying the test case.
Inlining the destructor caused the compiler to generate bad IR which failed the Verifier in the backend.
https://llvm.org/bugs/show_bug.cgi?id=30341
This patch disables alias to available_externally definitions.
Reviewers: eugenis, rsmith
Differential Revision: https://reviews.llvm.org/D24682
llvm-svn: 283063
When emitting the fundamental type information constants, inherit the
DLLExportAttr from `__fundamental_type_info`. We would previously not
honor the `__declspec(dllexport)` on the type information.
llvm-svn: 282980
Instead of ignoring the evaluation order rule, ignore the "destroy parameters
in reverse construction order" rule for the small number of problematic cases.
This only causes incorrect behavior in the rare case where both parameters to
an overloaded operator <<, >>, ->*, &&, ||, or comma are of class type with
non-trivial destructor, and the program is depending on those parameters being
destroyed in reverse construction order.
We could do a little better here by reversing the order of parameter
destruction for those functions (and reversing the argument evaluation order
for all direct calls, not just those with operator syntax), but that is not a
complete solution to the problem, as the same situation can be reached by an
indirect function call.
Approach reviewed off-line by rnk.
llvm-svn: 282777
Inlining the destructor caused the compiler to generate bad IR which failed the Verifier in the backend.
https://llvm.org/bugs/show_bug.cgi?id=30341
This patch disables alias to available_externally definitions.
Reviewers: eugenis, rsmith
Differential Revision: https://reviews.llvm.org/D24682
llvm-svn: 282679
function correctly when targeting MS ABIs (this appears to have never mattered
prior to this change).
Update test case to always cover both 32-bit and 64-bit Windows ABIs, since
they behave somewhat differently from each other here.
Update test case to also cover operators , && and ||, which it appears are also
affected by P0145R3 (they're not explicitly called out by the design document,
but this is the emergent behavior of the existing wording).
Original commit message:
P0145R3 (C++17 evaluation order tweaks): evaluate the right-hand side of
assignment and compound-assignment operators before the left-hand side. (Even
if it's an overloaded operator.)
This completes the implementation of P0145R3 + P0400R0 for all targets except
Windows, where the evaluation order guarantees for <<, >>, and ->* are
unimplementable as the ABI requires the function arguments are evaluated from
right to left (because parameter destructors are run from left to right in the
callee).
llvm-svn: 282619
assignment and compound-assignment operators before the left-hand side. (Even
if it's an overloaded operator.)
This completes the implementation of P0145R3 + P0400R0 for all targets except
Windows, where the evaluation order guarantees for <<, >>, and ->* are
unimplementable as the ABI requires the function arguments are evaluated from
right to left (because parameter destructors are run from left to right in the
callee).
llvm-svn: 282556
* recurse through intermediate LabelStmts and AttributedStmts when checking
whether a statement inside a switch declares a variable
* if the end of a compound statement is reachable from the chosen case label,
and the compound statement contains a variable declaration, it's not valid
to just emit the contents of the compound statement -- we must emit the
statement itself or we lose the scope (and thus end lifetimes at the wrong
point)
llvm-svn: 281797
virtual table offset in a member function pointer.
We are reserving this space for future ABI use relating to alternative
v-table configurations. In the meantime, continue to zero-initialize
this space when actually emitting a member pointer literal.
This will successfully interoperate with existing compilers.
Future versions of the compiler may place additional data in
this location, and at that point, code emitted by compilers
prior to this patch will fail if exposed to such a member pointer.
This is therefore a somewhat hard ABI break. However, because
it is limited to an uncommon case of an uncommon language feature,
and especially because interoperation with the standard library
does not depend on member pointers, we believe that with a
sufficiently advance compiler change the impact of this break
will be minimal in practice.
llvm-svn: 281693
r235815 changed CGRecordLowering::accumulateBases to ignore non-virtual
bases of size 0, which prevented adding those non-virtual bases to
CGRecordLayout's NonVirtualBases. This caused clang to assert when
CGRecordLayout::getNonVirtualBaseLLVMFieldNo was called in
EmitNullConstant. This commit fixes the bug by ignoring zero-sized
non-virtual bases in EmitNullConstant.
rdar://problem/28100139
Differential Revision: https://reviews.llvm.org/D24312
llvm-svn: 281405
In r246338, code was added to check for this, but it failed to take into
account implicit destructor invocations because those are not reflected
in the AST. This adds a separate check for them.
llvm-svn: 281395
We should be doing the same checks when a type is completed as we do
when a complete type is used during emission. Previously, we duplicated
the logic, and it got out of sync. This could be observed with
dllimported classes.
Also reduce a test case for this slightly.
Implementing review feedback from David Blaikie on r281057.
llvm-svn: 281278
MSVC emits /include directives in the .drective section for the
__dyn_tls_init function (decorated as ___dyn_tls_init@12 for 32-bit).
This fixes PR30347.
llvm-svn: 281189
The logic for upgrading a class from a forward decl to a complete type
was not checking the debug info emission level before applying the
vtable optimization. This meant we ended up without debug info for a
class which was required to be complete. I noticed it because it
triggered an assertion during CodeView emission, but that's a separate
issue.
llvm-svn: 281057
If a dynamic class contains a dllimport method, then assume the class
may not be constructed in this DLL, and therefore the vtable will live
in a different PDB.
This heuristic is still incomplete, and will miss things like abstract
base classes that are only constructed on one side of the DLL interface.
That said, this heuristic does detect some cases that are currently
problematic, and may be useful to other projects that don't use many
DLLs.
llvm-svn: 281053
Summary:
C++1z 6.4.1/p2:
If the if statement is of the form if constexpr, the value of the
condition shall be a contextually converted constant expression of type
bool [...]
C++1z 5.20/p4:
[...] A contextually converted constant expression of type bool is an
expression, contextually converted to bool (Clause4), where the
converted expression is a constant expression and the conversion
sequence contains only the conversions above. [...]
Contextually converting result of an expression `e` to a Boolean value
requires `bool t(e)` to be well-formed.
An explicit conversion function is only considered as a user-defined
conversion for direct-initialization, which is essentially what
//contextually converted to bool// requires.
Also, fixes PR28470.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24158
llvm-svn: 280838
Move the logic for doing this from the ABI argument lowering into
EmitParmDecl, which runs for all parameters. Our codegen is slightly
suboptimal in this case, as we may leave behind a dead store after
optimization, but it's 32-bit inalloca, and this fixes the bug in a
robust way.
Fixes PR30293
llvm-svn: 280836
If the virtual method comes from a secondary vtable, then the type of
the 'this' parameter should be i8*, and not a pointer to the complete
class. In the MS ABI, the 'this' parameter on entry points to the vptr
containing the virtual method that was called, so we use i8* instead of
the normal type. We had a mismatch where the CGFunctionInfo of the call
didn't match the CGFunctionInfo of the declaration, and this resulted in
some assertions, but now both sides agree the type of 'this' is i8*.
Fixes one issue raised in PR30293
llvm-svn: 280815
copy-initialization. We previously got this wrong in a couple of ways:
- we only looked for copy / move constructors and constructor templates for
this copy, and thus would fail to copy in cases where doing so should use
some other constructor (but see core issue 670),
- we mishandled the special case for disabling user-defined conversions that
blocks infinite recursion through repeated application of a copy constructor
(applying it in slightly too many cases) -- though as far as I can tell,
this does not ever actually affect the result of overload resolution, and
- we misapplied the special-case rules for constructors taking a parameter
whose type is a (reference to) the same class type by incorrectly assuming
that only happens for copy/move constructors (it also happens for
constructors instantiated from templates and those inherited from base
classes).
These changes should only affect strange corner cases (for instance, where the
copy constructor exists but has a non-const-qualified parameter type), so for
the most part it only causes us to produce more 'candidate' notes, but see the
test changes for other cases whose behavior is affected.
llvm-svn: 280776
Some Windows SDK classes, for example
Windows::Storage::Streams::IBufferByteAccess, use the ATL way of spelling
attributes:
[uuid("....")] class IBufferByteAccess {};
To be able to use __uuidof() to grab the uuid off these types, clang needs to
support uuid as a Microsoft attribute. There was already code to skip Microsoft
attributes, extend that to look for uuid and parse it. Use the new "Microsoft"
attribute type added in r280575 (and r280574, r280576) for this.
Final part of https://reviews.llvm.org/D23895
llvm-svn: 280578
Clang tests for verifying the following syntaxes:
1. 0xNN and NNh are accepted as valid hexadecimal numbers, but 0xNNh is not.
0xNN and NNh may come with optional U or L suffix.
2. NNb is accepted as a valid binary (base-2) number, but 0bNN is not.
NNb may come with optional U or L suffix.
Differential Revision: https://reviews.llvm.org/D22112
llvm-svn: 280556
Classes with no virtual methods or whose virtual methods were all
inherited from virtual bases don't have a vfptr at offset zero. We were
crashing attempting to get the layout of that non-existent vftable.
We don't need any vshape info in this case because the debugger can
infer it from the base class information. The current class may not
introduce any virtual methods if we are in this situation.
llvm-svn: 280287
The shape is really just the number of methods in the vftable, since we
don't support 16 bit far calls. All calls are near. Encode this number
in the size of the artificial __vtbl_ptr_type DIDerivedType that we
generate. For DWARF, this will be a normal pointer, but for codeview
this will be a wide pointer that gets pattern matched into a
VFTableShape record. Insert this type into the element list of all
dynamic classes when emitting CodeView, so that the backend can emit the
shape even if the vptr lives in a primary base class.
Fixes PR28150
llvm-svn: 280255
Otherwise we can't handle secondary base classes at offsets greater than
2**24. This agrees with libstdc++abi.
We could extend this change to other LLP64 platforms, but then we would
want to update libc++abi and it would require additional review.
Fixes PR29116
llvm-svn: 279786
This isn't exactly what MSVC does, unfortunately. MSVC does not pass
objects with destructors but no copy constructors by address. More ARM
expertise is required to really understand what should be done here.
Fixes PR29136.
llvm-svn: 279764
With -debug-info-kind=limited, we omit debug info for dynamic classes that live in other TUs. This reduces duplicate type information. When statically linked, the type information comes together. But if your binary has a class derived from a base in a DLL, the base class info is not available to the debugger.
The decision is made in shouldOmitDefinition (CGDebugInfo.cpp). Per a suggestion from rnk, I've tweaked the decision so that we do include definitions for classes marked as DLL imports. This should be a relatively small number of classes, so we don't pay a large price for duplication of the type info, yet it should cover most cases on Windows.
Essentially this makes debug info for DLLs independent, but we still assume that all TUs within the same DLL will be consistently built with (or without) debug info and the debugger will be able to search across the debug info within that scope to resolve any declarations into definitions, etc.
llvm-svn: 278861
For now just disregard the using declaration in this case. Suboptimal,
but wiring up the ability to have declarations of functions that are
separate from their definition (we currently only do that for member
functions) and have differing return types (we don't have any support
for that) is more work than seems reasonable to at least fix this crash.
llvm-svn: 277852
Summary:
Previously this crashed inside EmitThisParam(). There should be no
prelude for naked functions, so just skip the whole thing.
Reviewers: majnemer
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D22715
llvm-svn: 276925
This change depends on the corresponding LLVM change at:
https://reviews.llvm.org/D22519
The llvm.invariant.start and llvm.invariant.end intrinsics currently
support specifying invariant memory objects only in the default address
space.
With this LLVM change, these intrinsics are overloaded for any adddress space
for memory objects and we can use these llvm invariant intrinsics in
non-default address spaces.
Example: llvm.invariant.start.p1i8(i64 4, i8 addrspace(1)* %ptr)
This overloaded intrinsic is needed for representing final or invariant
memory in managed languages.
llvm-svn: 276448
Patch broke ModuleDebugInfo test on the build bots (but not locally). Again.
svn revision: r276271
This reverts commit 9da8a1b05362bc96f2855fb32b5588b89407685d.
llvm-svn: 276279
Unreferenced nested structs and classes were omitted from the debug info. In DWARF, this was intentional, to avoid bloat. But for CodeView, we want this information to be consistent with what Microsoft tools would produce and expect.
llvm-svn: 276271
This reverts also r275029, "Update Clang tests after adding inference for the returned argument attribute"
It broke LTO build. Seems miscompilation.
llvm-svn: 275756
David L. Jones