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
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
A BuiltinTemplateDecl has no underlying templated decl and as such they
cannot be relied upon for mangling. The ItaniumMangler had some bugs
here which lead to crashes.
This fixes PR28519.
llvm-svn: 275190
We need to mark the appropriate bits in ThrowInfo and HandlerType so
that the personality routine can correctly handle qualification
conversions.
llvm-svn: 275154
Reverting because it causes a test failure on build bots (Modules/ModuleDebugInfo.cpp). Failure does not reproduce locally.
svn revision: rL274698
This reverts commit 3c5ed6599b086720aab5b8bd6941149d066806a6.
llvm-svn: 274706
This should work now that the LLVM-side of the change has landed successfully.
Original Differential Revision: http://reviews.llvm.org/D21705
This reverts commit a30322e861c387e1088f47065d0438c6bb019879.
llvm-svn: 274698
This includes nested types in the member list, even if there are no members of that type. Note that structs and classes have themselves as an "implicit struct" as the first member, so we skip implicit ones.
Differential Revision: http://reviews.llvm.org/D21705
llvm-svn: 274628
member is redundantly redeclared outside the class definition in code built in
c++17 mode, ensure we emit a non-discardable definition of the data member for
c++11 and c++14 compilations to use.
llvm-svn: 274416
The CodeView printer expects to be able to generate fully qualified
names from the debug info graph. This means that we need to include the
MSVC-style name in the debug info for anonymous types.
llvm-svn: 274401
With all MaterializeTemporaryExprs coming with a ExprWithCleanups, it's
easy to add correct lifetime.end marks into the right RunCleanupsScope.
Differential Revision: http://reviews.llvm.org/D20499
llvm-svn: 274385
When -gmlt is on, we don't emit namespace or class scope information,
and the CodeView emission code in LLVM can't compute the fully qualified
name. If we know LLVM won't be able to get the name right, go ahead and
emit the qualified name in the frontend.
We could change our -gmlt emission strategy to include those scopes when
emitting codeview, but that would increase memory usage and slow down
LTO and add more complexity to debug info emission.
The same problem exists when you debug a -gmlt binary with GDB, so we
should consider removing '&& EmitCodeView' from the condition here at
some point in the future after evaluating the impact on object file
size.
llvm-svn: 274246
Original patch by Stefan Bühler http://reviews.llvm.org/D12834
Difference between original and this one:
- fixed all failing tests
- fixed mangling for global variable outside namespace
- emit ABI tags for guards and local names
- clang-format + other stylistic changes
- significantly reworked patch according to Richard's suggestions
Sema part, committed before http://reviews.llvm.org/D17567
Differential revision: http://reviews.llvm.org/D18035
llvm-svn: 274222
We didn't assign an inheritance model for 'Foo' if the event an
exrepssion like '&Foo::Bar' occured if 'Bar' could resolve to multiple
functions.
Once the overload set is resolved to a particular member, we enforce a
specific inheritance model.
This fixes PR28360.
llvm-svn: 274202
Emit the underlying storage offset in addition to the starting bit
position of the field.
This fixes PR28162.
Differential Revision: http://reviews.llvm.org/D21783
llvm-svn: 274201
Reverts r273305 and re-instates r273296.
We needed to fix a bug in Sema::MarkVTableUsed to ensure that operator
delete lookup occurs when the vtable is referenced. We already had a
special case to look up operator delete when dllimport was used, but I
think should really mark virtual destructors referenced any time the
vtable is used.
llvm-svn: 274147
Replace inheriting constructors implementation with new approach, voted into
C++ last year as a DR against C++11.
Instead of synthesizing a set of derived class constructors for each inherited
base class constructor, we make the constructors of the base class visible to
constructor lookup in the derived class, using the normal rules for
using-declarations.
For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived
class that tracks the requisite additional information. We create shadow
constructors (not found by name lookup) in the derived class to model the
actual initialization, and have a new expression node,
CXXInheritedCtorInitExpr, to model the initialization of a base class from such
a constructor. (This initialization is special because it performs real perfect
forwarding of arguments.)
In cases where argument forwarding is not possible (for inalloca calls,
variadic calls, and calls with callee parameter cleanup), the shadow inheriting
constructor is not emitted and instead we directly emit the initialization code
into the caller of the inherited constructor.
Note that this new model is not perfectly compatible with the old model in some
corner cases. In particular:
* if B inherits a private constructor from A, and C uses that constructor to
construct a B, then we previously required that A befriends B and B
befriends C, but the new rules require A to befriend C directly, and
* if a derived class has its own constructors (and so its implicit default
constructor is suppressed), it may still inherit a default constructor from
a base class
llvm-svn: 274049
Add support for /Ob1 (and equivalent -finline-hint-functions), which enable
inlining only for functions marked inline, either explicitly (via inline
keyword, for example), or implicitly (function definition in class body,
for example).
This works by enabling inlining pass, and adding noinline attribute to
every function not marked inline.
Patch by Rudy Pons <rudy.pons@ilod.org>!
Differential Revision: http://reviews.llvm.org/D20647
llvm-svn: 273440
MSVC doesn't provide them. PR28223
I left behind the machinery in case we want to resurrect available_externally
vftable emission to support devirtualization.
Reviewers: majnemer
Differential Revision: http://reviews.llvm.org/D21544
llvm-svn: 273296
The export side is responsible for running any initializers, they are
run when the module is first loaded. Attempting to run an initializer
for the import side is not possible.
This fixes PR28216.
llvm-svn: 273237
This patch fixes a bug where we'd segfault (in some cases) if we saw a
variadic function with one or more pass_object_size arguments.
Differential Revision: http://reviews.llvm.org/D17462
llvm-svn: 272971
Parameters and non-static members of aggregates are still excluded,
and probably should remain that way.
Differential Revision: http://reviews.llvm.org/D19754
llvm-svn: 272859
Summary:
This is similar to other loop pragmas like 'vectorize'. Currently it
only has state values: distribute(enable) and distribute(disable). When
one of these is specified the corresponding loop metadata is generated:
!{!"llvm.loop.distribute.enable", i1 true/false}
As a result, loop distribution will be attempted on the loop even if
Loop Distribution in not enabled globally. Analogously, with 'disable'
distribution can be turned off for an individual loop even when the pass
is otherwise enabled.
There are some slight differences compared to the existing loop pragmas.
1. There is no 'assume_safety' variant which makes its handling slightly
different from 'vectorize'/'interleave'.
2. Unlike the existing loop pragmas, it does not have a corresponding
numeric pragma like 'vectorize' -> 'vectorize_width'. So for the
consistency checks in CheckForIncompatibleAttributes we don't need to
check it against other pragmas. We just need to check for duplicates of
the same pragma.
Reviewers: rsmith, dexonsmith, aaron.ballman
Subscribers: bob.wilson, cfe-commits, hfinkel
Differential Revision: http://reviews.llvm.org/D19403
llvm-svn: 272656
Summary:
This should have been a very simple change, but it was greatly
complicated by the construction of new Decls during IR generation.
In particular, we reconstruct the AST function type in order to get the
implicit 'this' parameter into C++ method types.
We also have to worry about FunctionDecls whose types are not
FunctionTypes because CGBlocks.cpp constructs some dummy FunctionDecls
with 'void' type.
Depends on D21114
Reviewers: aprantl, dblaikie
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D21141
llvm-svn: 272198
We attempted to use the UnaryTransformType's UnderlyingType instead of
it's BaseType. This is not correct for dependent UnaryTransformType
because the have no underlying type.
This fixes PR28045.
llvm-svn: 272079
Problem found by Nico, originally committed by me in r213213. The .test
prefix wasn't actually being run. Once that was fixed the test cases had
outdated command line syntax and IR debug info format, so updated for
those issues to get them back up and running.
Thanks Nico!
llvm-svn: 271188
It seems that suffix '@4HA' was omitted for unknown reason. It is
non-cont non-volatile 'int' type of normal variable TSS.
Differential revision: http://reviews.llvm.org/D20683
llvm-svn: 270974
Also make explicit instantiation decls not apply to nested classes when
targeting MSVC. That dll attributes are not inherited by inner classes
might be the explanation for MSVC's behaviour here.
llvm-svn: 270897
This implements support for MS-specific __unaligned qualifier in functions and
makes the following test case both compile and mangle correctly:
struct S {
void f() __unaligned;
};
void S::f() __unaligned {
}
Differential Revision: http://reviews.llvm.org/D20437
llvm-svn: 270834
If the callee has a valid location (not all do), then use that. Otherwise, fall
back to the starting location. This makes sure that the debug info for calls
points to the call (not the start of the expression providing the object on
which the member function is being called).
For example, given this:
f->foo()->bar();
we don't want both calls to point to the 'f', but rather to the 'foo()' and
the 'bar()'.
Fixes PR27567.
Differential Revision: http://reviews.llvm.org/D19708
llvm-svn: 270775
Getting accurate locations for loops is important, because those locations are
used by the frontend to generate optimization remarks. Currently, optimization
remarks for loops often appear on the wrong line, often the first line of the
loop body instead of the loop itself. This is confusing because that line might
itself be another loop, or might be somewhere else completely if the body was
an inlined function call. This happens because of the way we find the loop's
starting location. First, we look for a preheader, and if we find one, and its
terminator has a debug location, then we use that. Otherwise, we look for a
location on an instruction in the loop header.
The fallback heuristic is not bad, but will almost always find the beginning of
the body, and not the loop statement itself. The preheader location search
often fails because there's often not a preheader, and even when there is a
preheader, depending on how it was formed, it sometimes carries the location of
some preceeding code.
I don't see any good theoretical way to fix this problem. On the other hand,
this seems like a straightforward solution: Put the debug location in the
loop's llvm.loop metadata. When emitting debug information, this commit causes
us to add the debug location as an operand to each loop's llvm.loop metadata.
Thus, we now generate this metadata for all loops (not just loops with
optimization hints) when we're otherwise generating debug information.
The remark test case changes depend on the companion LLVM commit r270771.
llvm-svn: 270772
This matches what MSVC does, and should make compiles faster by avoiding to
unnecessarily emit a lot of code.
Differential Revision: http://reviews.llvm.org/D20608
llvm-svn: 270748
If we have some function with dllimport attribute and then we have the function
definition in the same module but without dllimport attribute we should add
dllexport attribute to this function definition.
The same should be done for variables.
Example:
struct __declspec(dllimport) C3 {
~C3();
};
C3::~C3() {;} // we should export this definition.
Patch by Andrew V. Tischenko
Differential revision: http://reviews.llvm.org/D18953
llvm-svn: 270686
Clang doesn't dllexport defaulted special member function defaulted
inside class but does it if they defaulted outside class. MSVC doesn't
make any distinction where they were defaulted. Also MSVC 2013 and 2015
export different set of members. MSVC2015 doesn't emit trivial defaulted
x-tors but does emit copy assign operator.
Differential revision: http://reviews.llvm.org/D20422
llvm-svn: 270535
A constructor needs to know whether or not it is most derived in order
to determine if it is responsible for virtual bases. Delegating
constructors assumed they were most derived.
llvm-svn: 269465
Clang creates implicit move constructor/assign operator in all cases if
there is std=c++11. But MSVC supports such generation starting from
version 1900 only. As result we have some binary incompatibility.
Differential Revision: http://reviews.llvm.org/D19156
Patch by Andrew V. Tischenko
llvm-svn: 269400
Bases can be zero-initialized: the storage is zero-initialized before
the base constructor is run.
The MS ABI has a quirk where base VBPtrs are not installed by the
base constructor but by the most derived class. In particular, they are
installed before the base constructor is run.
The derived constructor must be careful to zero-initialize only the bits
of the class which haven't already been populated by virtual base
pointers.
While we correctly avoided this scenario, we didn't handle the case
where the base class has virtual bases which have virtual bases.
llvm-svn: 269271
This patch implements __unaligned (MS extension) as a proper type qualifier
(before that, it was implemented as an ignored attribute).
It also fixes PR27367 and PR27666.
Differential Revision: http://reviews.llvm.org/D20103
llvm-svn: 269220
Faisal Vali