The variable (and the GV) is only ever used if the function is. Putting it
in the function's comdat make it easier for the linker to discard them.
The motivating example is
struct S {
static const int x;
};
// const int S::x = 42;
inline const int *f() {
static const int y = S::x;
return &y;
}
const int *g() { return f(); }
With S::x commented out, _ZZ1fvE1y is a variable with a guard variable
that is initialized by f.
With S::x present, _ZZ1fvE1y is a constant.
llvm-svn: 224369
We that static variables in function template specializations were
externally visible. The manglers assumed that externally visible static
variables were numbered in Sema. We would end up mangling static
variables in the same specialization with the same mangling number which
would give all of them the same name.
This fixes PR21904.
llvm-svn: 224316
This actually came up as a break in UBSan tests (look for a follow-up
commit to this one to see the UBSan test fallout) when I tried a broader
fix to location information.
I have some other ideas about how to do that broader change & will keep
looking into it.
llvm-svn: 224221
CodeGen assumed that a compound literal with array type should have a
corresponding LLVM IR array type.
We had two bugs in this area:
- Zero sized arrays in compound literals would lead to the creation of
an opaque type. This is unnecessary, we should just create an array
type with a bound of zero.
- Funny record types (like unions) lead to exotic IR types for compound
literals. In this case, CodeGen must be prepared to deal with the
possibility that it might not have an array IR type.
This fixes PR21912.
llvm-svn: 224219
The extension has the following syntax:
__builtin_call_with_static_chain(Call, Chain)
where Call must be a function call expression and Chain must be of pointer type
This extension performs a function call Call with a static chain pointer
Chain passed to the callee in a designated register. This is useful for
calling foreign language functions whose ABI uses static chain pointers
(e.g. to implement closures).
Differential Revision: http://reviews.llvm.org/D6332
llvm-svn: 224167
A discriminator is used for the first occurrence of a name.
inline int f1 () {
static union {
int a;
long int b;
};
static union {
int c;
double d;
};
return a+c;
}
The name of the second union is mangled as _ZZ2f1vE1c_0 instead of _ZZ2f1vE1c.
Differential Revision: http://reviews.llvm.org/D6295
llvm-svn: 224131
This particularly helps the fidelity of ASan reports (which can occur
even in these examples - if, for example, one uses placement new over a
buffer of insufficient size - now ASan will correctly identify which
member's initialization went over the end of the buffer).
This doesn't cover all types of members - more coming.
llvm-svn: 223726
is for each machine. Fix up darwin tests that were testing for
aapcs on armv7-ios when the actual ABI is apcs.
Should be no user visible change without -cc1.
llvm-svn: 223429
We currently use i32 (...)** as the type of the vptr field in the LLVM
struct type. LLVM's GlobalOpt prefers any bitcasts to be on the side of
the data being stored rather than on the pointer being stored to.
Reviewers: majnemer
Differential Revision: http://reviews.llvm.org/D5916
llvm-svn: 223267
Consider this program:
struct A {
virtual void operator-() { printf("base\n"); }
};
struct B final : public A {
virtual void operator-() override { printf("derived\n"); }
};
int main() {
B* b = new B;
-static_cast<A&>(*b);
}
Before this patch, clang saw the virtual call to A::operator-(), figured out
that it can be devirtualized, and then just called A::operator-() directly,
without going through the vtable. Instead, it should've looked up which
operator-() the call devirtualizes to and should've called that.
For regular virtual member calls, clang gets all this right already. So
instead of giving EmitCXXOperatorMemberCallee() all the logic that
EmitCXXMemberCallExpr() already has, cut the latter function into two pieces,
call the second piece EmitCXXMemberOrOperatorMemberCallExpr(), and use it also
to generate code for calls to virtual member operators.
This way, virtual overloaded operators automatically don't get devirtualized
if they have covariant returns (like it was done for regular calls in r218602),
etc.
This also happens to fix (or at least improve) codegen for explicit constructor
calls (`A a; a.A::A()`) in MS mode with -fsanitize-address-field-padding=1.
(This adjustment for virtual operator calls seems still wrong with the MS ABI.)
llvm-svn: 223185
There was no test coverage for this before: Modifiying
EmitCXXOperatorMemberCallee() to not call CanDevirtualizeMemberFunctionCall()
didn't make any test fail.
llvm-svn: 223056
Now that TailRecursionElimination has been fixed with r222354, the
threshold on size for lifetime marker insertion can be removed. This
only affects named temporary though, as the patch for unnamed temporaries
is still in progress.
llvm-svn: 222993
Now that LLVM can count the registers needed to implement AAPCS rules, we don't
need to duplicate that logic here. This means we can drop the explicit padding
and also use more natural types in many cases (e.g. "struct { float arr[3]; }"
used to end up as "[2 x double]" to avoid holes on the stack.
The one wrinkle is that AAPCS va_arg was also using the register counting
machinery. But the local replacement isn't too bad.
llvm-svn: 222904
The Mips target adds the signext attribute to signed 32-bit integers in order
to support the N32/N64 correctly. Integers must be promoted to 64-bit bit on
these ABI's.
llvm-svn: 222617
We previously had support for char and wchar_t string literals. VS 2015
added support for char16_t and char32_t.
String literals must be mangled in the MS ABI in order for them to be
deduplicated across translation units: their linker has no notion of
mergeable section. Instead, they use the mangled name to make a COMDAT
for the string literal; the COMDAT will merge with other COMDATs in
other object files.
This allows strings in object files generated by clang to get merged
with strings in object files generated by MSVC.
llvm-svn: 222564
Currently this function would return nothing for functions or globals that
haven't seen a definition yet. Make it return a forward declaration that will
get RAUWed with the definition if one is seen at a later point. The strategy
used to implement this is similar to what's done for types: the forward
declarations are stored in a vector and post processed upon finilization to
perform the required RAUWs.
For now the only user of getDeclarationOrDefinition() is EmitUsingDecl(), thus
this patch allows to emit correct imported declarations even in the absence of
an actual definition of the imported entity.
(Another user will be the debug info generation for argument default values
that I need to resurect).
Differential Revision: http://reviews.llvm.org/D6173
llvm-svn: 222220
used inside blocks. It fixes a crash in naming code
for __func__ etc. when used in a block declared globally.
It also brings back old naming convention for
predefined expression which was broken. rdar://18961148
llvm-svn: 222065
This option was misleading because it looked like it enabled the
language feature of SEH (__try / __except), when this option was really
controlling which EH personality function to use. Mingw only supports
SEH and SjLj EH on x86_64, so we can simply do away with this flag.
llvm-svn: 221963
The check for unnamed members was intended to skip unnamed bitfields,
but it ended up skipping unnamed structs. This lead to an assertion in
IRGen.
llvm-svn: 221818
Summary:
This change makes CodeGenFunction::EmitCheck() take several
conditions that needs to be checked (all of them need to be true),
together with sanitizer kinds these checks are for. This would allow
to split one call into UBSan runtime into several calls in case
different sanitizer kinds would have different recoverability
settings.
Tests should be fixed accordingly, I'm working on it.
Test Plan: regression test suite.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6219
llvm-svn: 221716
So DWARF5 specs out auto deduced return types as DW_TAG_unspecified_type
with DW_AT_name "auto", and GCC implements this somewhat, but it
presents a few problems to do this with Clang.
GCC's implementation only applies to member functions where the auto
return type isn't deduced immediately (ie: member functions of templates
or member functions defined out of line). In the common case of an
inline deduced return type function, GCC emits the DW_AT_type as the
deduced return type.
Currently GDB doesn't seem to behave too well with this debug info - it
treats the return type as 'void', even though the definition of the
function has the correctly deduced return type (I guess it sees the
return type the declaration has, doesn't understand it, and assumes
void). This means the function's ABI might be broken (non-trivial return
types, etc), etc.
Clang, on the other hand doesn't track this particular case of a
deducable return type that is deduced immediately versus one that is
deduced 'later'. So if we implement the DWARF5 representation, all
deducible return type functions would get adverse GDB behavior
(including deduced return type lambda functions, inline deduced return
type functions, etc).
Also, we can't just do this for auto types that are not deduced -
because Clang marks even the declaration's return type as deduced (&
provides the underlying type) once a definition is seen that allows the
deduction. So we have to ignore even deduced types - but we can't do
that for auto variables (because this representation only applies to
function declarations - variables and function definitions need the real
type so the function can be called, etc) so we'd need to add an extra
flag to the type unwrapping/creation code to indicate when we want to
see through deduced types and when we don't. It's also not as simple as
just checking at the top level when building a function type (for one
thing, we reuse the function type building for building function pointer
types which might also have 'auto' in them - but be the type of a
variable instead) because the auto might be arbitrarily deeply nested
("auto &", "auto (*)()", etc...)
So, with all that said, let's do the simple thing that works in existing
debuggers for now and treat these functions the same way we do function
templates and implicit special members: omit them from the member list,
since they can't be correctly called anyway (without knowing the return
type the ABI isn't know and a function call could put the arguments in
the wrong place) so they're not much use to the user.
At some point in the future, when GDB understands the DWARF5
representation better it might be worth plumbing through the extra type
builder handling to avoid looking through AutoType for some callers,
etc...
llvm-svn: 221704
an __unknown_anytype(...). In this case, we rebuild the
vararg function type specially to convert the call expression
to something that IRGen can handle. However, FunctionDecl
as rebuilt in RebuildUnknownAnyExpr::resolveDecl is bogus and
results in crash when accessing its params later on. This
patch fixes the crash by rebuilding the FunctionDecl to match
its new resolved type. rdar://15297105.
(patch reapplied after lldb issue was fixed in r221660).
llvm-svn: 221691
This is a new form of expression of the form:
(expr op ... op expr)
where one of the exprs is a parameter pack. It expands into
(expr1 op (expr2onwards op ... op expr))
(and likewise if the pack is on the right). The non-pack operand can be
omitted; in that case, an empty pack gives a fallback value or an error,
depending on the operator.
llvm-svn: 221573
Homogeneous aggregates on AAPCS_VFP ARM need to be passed *without* being
flattened (e.g. [2 x float] rather than "float, float") for various weird ABI
reasons. However, this isn't the case for anything else; further, we know at
the ABIArgInfo::getDirect callsites whether this flattening is allowed.
So, we can get more unified ARM code, with a simpler Clang, by just using that
knowledge directly.
llvm-svn: 221559
We would blindly assume that RTTI data should have the same linkage as
the vtable because we didn't think the RTTI data was external. This
oversight stemmed because we didn't take dllimport into account.
This fixes PR21512.
llvm-svn: 221511
an __unknown_anytype(...). In this case, we rebuild the
vararg function type specially to convert the call expression
to something that IRGen can handle. However, FunctionDecl
as rebuilt in RebuildUnknownAnyExpr::resolveDecl is bogus and
results in crash when accessing its params later on. This
patch fixes the crash by rebuilding the FunctionDecl to match
its new resolved type. rdar://15297105.
John McCall, please review post-commit.
llvm-svn: 221404
When we are generating the global initializer functions, we call
CGDebugInfo::EmitFunctionStart() with a valid decl which is describing
the initialized global variable. Do not update the DeclCache with this
key as it will overwrite the the cached variable DIGlobalVariable with
the newly created artificial DISubprogram.
One could wonder if we should put artificial subprograms in the DIE tree
at all (there are vaild uses for them carrying line information though).
llvm-svn: 221385
It turns out that MinGW never dllimports of exports inline functions.
This means that code compiled with Clang would fail to link with
MinGW-compiled libraries since we might try to import functions that
are not imported.
To fix this, make Clang never dllimport inline functions when targeting
MinGW.
llvm-svn: 221154
The most complex aspect of the convention is the handling of homogeneous
vector and floating point aggregates. Reuse the homogeneous aggregate
classification code that we use on PPC64 and ARM for this.
This convention also has a C mangling, and we apparently implement that
in both Clang and LLVM.
Reviewed By: majnemer
Differential Revision: http://reviews.llvm.org/D6063
llvm-svn: 221006
Summary:
The Itanium ABI approach of using offset-to-top isn't possible with the
MS ABI, it doesn't have that kind of information lying around.
Instead, we do the following:
- Call the virtual deleting destructor with the "don't delete the object
flag" set. The virtual deleting destructor will return a pointer to
'this' adjusted to the most derived class.
- Call the global delete using the adjusted 'this' pointer.
Reviewers: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5996
llvm-svn: 220993
Reuse the PPC64 HVA detection algorithm for ARM and AArch64. This is a
nice code deduplication, since they are roughly identical. A few virtual
method extension points are needed to understand how big an HVA can be
and what element types it can have for a given architecture.
Also make the record expansion code work in the presence of non-virtual
bases.
Reviewed By: uweigand, asl
Differential Revision: http://reviews.llvm.org/D6045
llvm-svn: 220972
The MS linker cannot do anything interesting with these, it doesn't make
sense to emit them.
This fixes PR21373.
Differential Revision: http://reviews.llvm.org/D5986
llvm-svn: 220595
Template template parameters weren't added to the list of substitutions.
This would make the substitution map contain inaccurate mappings,
leading to Clang violating the Itanium ABI and breaking compatibility
with GCC.
This fixes PR21351.
Differential Revision: http://reviews.llvm.org/D5959
llvm-svn: 220588
This fixes a corner-case where __uuidof as a template argument would
result in us trying to emit a GLValue as an RValue. This would lead to
a crash down the road.
llvm-svn: 220585
Wire it through everywhere we have support for fastcall, essentially.
This allows us to parse the MSVC "14" CTP headers, but we will
miscompile them because LLVM doesn't support __vectorcall yet.
Reviewed By: Aaron Ballman
Differential Revision: http://reviews.llvm.org/D5808
llvm-svn: 220573
Summary:
Ensure all integral/enumeration types are appropriately annotated with
signext/zeroext. In particular, i32 now has these attributes when using the
N32/N64 ABI. This paves the way for accurately representing the way the
N32/N64 ABI's promotes integer arguments to i64.
Reviewers: atanasyan
Reviewed By: atanasyan
Subscribers: cfe-commits, theraven
Differential Revision: http://reviews.llvm.org/D5961
llvm-svn: 220563
Clang would previously assert on the following code when targeting MinGW:
struct __declspec(dllimport) S {
virtual ~S();
};
S::~S() {}
Because ~S is a key function and the class is dllimport, we would try to emit a
strong definition of the vtable, with dllimport - which is a conflict. We
should not emit strong vtable definitions for imported classes.
Differential Revision: http://reviews.llvm.org/D5944
llvm-svn: 220532
The previous IR representation used the non-lexical decl context, which
placed the definitions in the same scope as the declarations (ie: within
the class) - this was hidden by the fact that LLVM currently doesn't
respect the context of global variable definitions at all, and always
puts them at the top level (as direct children of the compile_unit).
Having the correct lexical scope improves source fidelity and simplify
backend global variable emission (with changes coming shortly).
Doing something similar for non-member global variables would help
simplify/cleanup things further (see FIXME in the commit) and provide
similar source fidelity benefits to the final debug info.
llvm-svn: 220488
This eliminates some i8* GEPs and makes the IR that clang emits a bit
more canonical. More work is needed for vftables, but that isn't a clear
win so I plan to send it for review.
llvm-svn: 220398
This reverts commit r220169 which reverted r220153. However, it also
contains additional changes:
- We may need to add padding *after* we've packed the struct. This
occurs when the aligned next field offset is greater than the new
field's offset. When this occurs, we make the struct packed.
*However*, once packed the next field offset might be less than the
new feild's offset. It is in this case that we might further pad the
struct.
- We would pad structs which were perfectly sized! This behavior is
immensely old. This behavior came from blindly subtracting
NextFieldOffsetInChars from RecordSize. This doesn't take into
account the fact that the struct might have a greater overall
alignment than the last field.
llvm-svn: 220175
Plumb through the full QualType of the TemplateArgument::Declaration, as
it's insufficient to only know whether the type is a reference or
pointer (that was necessary for mangling, but insufficient for debug
info). This shouldn't increase the size of TemplateArgument as
TemplateArgument::Integer is still longer by another 32 bits.
Several bits of code were testing that the reference-ness of the
parameters matched, but this seemed to be insufficient (various other
features of the type could've mismatched and wouldn't've been caught)
and unnecessary, at least insofar as removing those tests didn't cause
anything to fail.
(Richard - perchaps you can hypothesize why any of these checks might
need to test reference-ness of the parameters (& explain why
reference-ness is part of the mangling - I would've figured that for the
reference-ness to be different, a prior template argument would have to
be different). I'd be happy to add them in/beef them up and add test
cases if there's a reason for them)
llvm-svn: 219900
Separate out the non-nullable parameters from the nullable ones
(currently only the template template parameter) and demonstrate that
cv-qualifiers aren't preserved for non-null parameters (but are
preserved for null parameters) by adding 'const' to an int* non-type
template parameter.
llvm-svn: 219883
In particular, if you have two identical templates in different TUs in
anonymous namespaces, we would use the same global_ctors comdat key for
both. As a result, only one would be run.
llvm-svn: 219806
Unions are initialized with the default initialization of their first
named member. If that member is not zero initialized, then we should
prefer that member's type. Otherwise, we might try to make an otherwise
unsuitable type (like an array) which we cannot easily initialize with a
pointer to member.
llvm-svn: 219781
When lazily constructing static member variable declarations (when
the vtable optimization fires and the definition of the type is omitted
(or built later, lazily), but the out of line definition of the static
member is provided and must be described in debug info) ensure we use
the canonical declaration when computing the file, line, etc for that
declaration (rather than the definition, which is also a declaration,
but not the canonical one).
llvm-svn: 219736
This change adds UBSan check to upcasts. Namely, when we
perform derived-to-base conversion, we:
1) check that the pointer-to-derived has suitable alignment
and underlying storage, if this pointer is non-null.
2) if vptr-sanitizer is enabled, and we perform conversion to
virtual base, we check that pointer-to-derived has a matching vptr.
llvm-svn: 219642
While we ran getUnqualifiedType over the catch type,
it isn't enough for array types. Use getUnqualifiedArrayType instead.
This fixes PR21252.
llvm-svn: 219582
It's possible to construct cases where the first field we are trying to
copy is in the middle of an IR field. In some complicated cases, we
would fail to use an appropriate offset inside the object. Earlier
builds of clang seemed to miscompile the code by copying an insufficient
number of bytes. Up until now, we would assert: the copying offset was
insufficiently aligned.
This fixes PR21232.
llvm-svn: 219524
Assertion failed: "Computed __func__ length differs from type!"
Reworked PredefinedExpr representation with internal StringLiteral field for function declaration.
Differential Revision: http://reviews.llvm.org/D5365
llvm-svn: 219393
Boostrapping LLVM+Clang+LLDB without threshold on object size for
lifetime markers insertion has shown there was no significant change
in compile time, so let the stack slot colorizer do its optimization
for all slots.
llvm-svn: 219303
Summary:
Previously CodeGen assumed that static locals were emitted before they
could be accessed, which is true for automatic storage duration locals.
However, it is possible to have CodeGen emit a nested function that uses
a static local before emitting the function that defines the static
local, breaking that assumption.
Fix it by creating the static local upon access and ensuring that the
deferred function body gets emitted. We may not be able to emit the
initializer properly from outside the function body, so don't try.
Fixes PR18020. See also previous attempts to fix static locals in
PR6769 and PR7101.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4787
llvm-svn: 219265
We used to avoid these, but it looks like we did so just because we were
not handling dllexport alias correctly.
Dario Domizioli fixed that, so allow these aliases.
Based on a patch by Dario Domizioli!
llvm-svn: 219206
By leaving these members out of the member list, we avoid them being
emitted into type unit definitions - while still allowing the
definition/declaration to be injected into the compile unit as expected.
llvm-svn: 219101
By leaving these members out of the member list, we avoid them being
emitted into type unit definitions - while still allowing the
definition/declaration to be injected into the compile unit as expected.
llvm-svn: 219100
This changes the scope discriminator's behavior to start at '1' instead
of '0'. Symbol table diffing, for ABI compatibility testing, kept
finding these as false positives.
llvm-svn: 219075
Summary:
This add support for the C++11 feature, thread_local global variables.
The ABI Clang implements is an improvement of the MSVC ABI. Sadly,
further improvements could be made but not without sacrificing ABI
compatibility.
The feature is implemented as follows:
- All thread_local initialization routines are pointed to from the
.CRT$XDU section.
- All non-weak thread_local variables have their initialization routines
call from a single function instead of getting their own .CRT$XDU
section entry. This is done to open up optimization opportunities to
the compiler.
- All weak thread_local variables have their own .CRT$XDU section entry.
This entry is in a COMDAT with the global variable it is initializing;
this ensures that we will initialize the global exactly once.
- Destructors are registered in the initialization function using
__tlregdtor.
Differential Revision: http://reviews.llvm.org/D5597
llvm-svn: 219074
This reverts commit r218917, effectively reapplying r218913. Original
commit message follows.
--
Update debug info testcases for an LLVM metadata schema change to fold
metadata constant operands into a single `MDString`.
Part of PR17891.
llvm-svn: 219011
Update debug info testcases for an LLVM metadata schema change to fold
metadata constant operands into a single `MDString`.
Part of PR17891.
llvm-svn: 218913
Summary:
Currently, with struct my_struct { int x; method_ptr y; };
a call to foo(my_struct s) may end up dropping the last 4 bytes
of the method pointer for x86_64 NaCl and x32.
When checking Has64BitPointers, also check if the method pointer
straddles an eightbyte boundary and classify Hi as well as Lo if needed.
Test Plan: test/CodeGenCXX/x86_64-arguments-nacl-x32.cpp
Reviewers: dschuff, pavel.v.chupin
Subscribers: jfb
Differential Revision: http://reviews.llvm.org/D5555
llvm-svn: 218889
Complex address expressions are no longer part of DIVariable, but
rather an extra argument to the debug intrinsics.
http://reviews.llvm.org/D4919
rdar://problem/17994491
llvm-svn: 218788
Complex address expressions are no longer part of DIVariable, but
rather an extra argument to the debug intrinsics.
http://reviews.llvm.org/D4919
rdar://problem/17994491
llvm-svn: 218777
Clang warns (treated as error by default, but still ignored in system headers)
when passing non-POD arguments to variadic functions, and generates a trap
instruction to crash the program if that code is ever run.
Unfortunately, MSVC happily generates code for such calls without a warning,
and there is code in system headers that use it.
This makes Clang not insert the trap instruction when in -fms-compatibility
mode, while still generating the warning/error message.
Differential Revision: http://reviews.llvm.org/D5492
llvm-svn: 218640
Fixes incorrect codegen when devirtualization is aborted due to covariant return types.
Differential Revision: http://reviews.llvm.org/D5321
llvm-svn: 218602
Clang uses two types to talk about a C++ class, the
NonVirtualBaseLLVMType and the LLVMType. Previously, we would allow one
of these to be packed and the other not.
This is problematic. If both don't agree on a common subset of fields,
then routines like getLLVMFieldNo will point to the wrong field. Solve
this by copying the 'packed'-ness of the complete type to the
non-virtual subobject. For this to work, we need to take into account
the non-virtual subobject's size and alignment when we are computing the
layout of the complete object.
This fixes PR21089.
llvm-svn: 218577
(clang crashed in CodeGen in llvm::Module::getNamedValue on
thread_local std::unique_ptr<int>).
Differential Revision: http://reviews.llvm.org/D5353
llvm-svn: 218503
On further investigation, COMDATs should work with .ctors, and the issue
I was hitting probably reproduces with .init_array.
This reverts commit r218287.
llvm-svn: 218313
Don't mangle all casts in expressions as "cv", use the appropriate
encoding which corresponds to a specific cast.
This fixes PR21034.
Differential Revision: http://reviews.llvm.org/D5453
llvm-svn: 218293
In particular, pre-.init_array ELF uses the .ctors section mechanism.
MinGW COFF also uses .ctors, now that I think about it. Therefore,
restrict this optimization to the two platforms that are currently known
to work: ELF with .init_array and COFF with .CRT$XCU.
llvm-svn: 218287
We need to walk the class hierarchy twice: once in depth-first base
specifier order for mangling and again in depth-first layout order for
vftable layout.
Vftable layout seems to depend on the full path from the most derived
class to the base containing the vfptr.
Fixes PR21031.
llvm-svn: 218285
This patch makes sure that the dllexport attribute is transferred to the alias when such alias is created. It only affects the Itanium ABI because for the MSVC ABI a workaround is in place to not generate aliases of dllexport ctors/dtors.
A new CodeGenModule function is provided, CodeGenModule::setAliasAttributes, to factor the code for transferring attributes to aliases.
llvm-svn: 218159
Clang can already handle
-------------------------------------------
struct S {
static const int x;
};
template<typename T> struct U {
static const int k;
};
template<typename T> const int U<T>::k = T::x;
const int S::x = 42;
extern const int *f();
const int *g() { return &U<S>::k; }
int main() {
return *f() + U<S>::k;
}
const int *f() { return &U<S>::k; }
-------------------------------------------
since r217264 which puts the .inint_array section in the same COMDAT
as the variable.
This patch allows the linker to more easily delete some dead code and data by
putting the guard variable and init function in the same COMDAT.
This is a fixed version of r218089.
llvm-svn: 218141
The field is defined as:
If the third field is present, non-null, and points to a global variable or function, the initializer function will only run if the associated data from the current module is not discarded.
And without COMDATs we can't implement that.
llvm-svn: 218097
Clang can already handle
-------------------------------------------
struct S {
static const int x;
};
template<typename T> struct U {
static const int k;
};
template<typename T> const int U<T>::k = T::x;
const int S::x = 42;
extern const int *f();
const int *g() { return &U<S>::k; }
int main() {
return *f() + U<S>::k;
}
const int *f() { return &U<S>::k; }
-------------------------------------------
since r217264 which puts the .inint_array section in the same COMDAT
as the variable.
This patch allows the linker to more easily delete some dead code and data by
putting the guard variable and init function in the same COMDAT.
llvm-svn: 218089
CodeGen would try to come up with an LLVM IR type for a pointer to
member type on the way to forming an LLVM IR type for a pointer to
pointer to member type.
However, if the pointer to member representation has not been locked in yet,
we would not be able to come up with a pointer to member IR type.
In these cases, make the pointer to member type an incomplete type.
This will make the pointer to pointer to member type a pointer to an
incomplete type. If the class eventually obtains an inheritance model,
we will make the pointer to member type represent the actual inheritance
model.
Differential Revision: http://reviews.llvm.org/D5373
llvm-svn: 218084
There are situations when clang knows that the C1 and C2 constructors
or the D1 and D2 destructors are identical. We already optimize some
of these cases, but cannot optimize it when the GlobalValue is
weak_odr.
The problem with weak_odr is that an old TU seeing the same code will
have a C1 and a C2 comdat with the corresponding symbols. We cannot
suddenly start putting the C2 symbol in the C1 comdat as we cannot
guarantee that the linker will not pick a .o with only C1 in it.
The solution implemented by GCC is to expand the ABI to have a comdat
whose name uses a C5/D5 suffix and always has both symbols. That is
what this patch implements.
llvm-svn: 217874
This adds a flag called -fseh-exceptions that uses the native Windows
.pdata and .xdata unwind mechanism to throw exceptions. The other EH
possibilities are DWARF and SJLJ exceptions.
Patch by Martell Malone!
Reviewed By: asl, rnk
Differential Revision: http://reviews.llvm.org/D3419
llvm-svn: 217790
Deleted virtual functions get _purecall inserted into the vftable.
Earlier CTPs would simply stick nullptr in there.
N.B. MSVC can't handle deleted virtual functions which require return
adjusting thunks, they give an error that a deleted function couldn't be
called inside of a compiler generated function. We get this correct by
making the thunk have a __purecall entry as well.
llvm-svn: 217654
We assumed that the incoming this argument would be the last argument.
However, this is not true under the MS ABI.
This fixes PR20897.
llvm-svn: 217642
This prevents initializers for comdat-folded globals from running multiple times.
Differential Revision: http://reviews.llvm.org/D5281
llvm-svn: 217534
Pointer-sized alignment is sufficient as we only ever read single values
from the table. Otherwise we'd bump the alignment to 16 bytes in the
backend if the vtable is larger than 16 bytes. This is great for
structures that are accessed with vector instructions or copied around, but
that's simply not the case for vtables.
Shrinks the data segment of a Release x86_64 clang by 0.3%. The wins are
larger for i386 and code bases that use vtables more often than we do.
This matches the behavior of GCC 5.
llvm-svn: 217495
InstCombine just got a bit smarter about checking known bits of returned
values, and because this test runs the optimizer, it requires an update. We
should really rewrite this test to directly check the IR output from CodeGen.
llvm-svn: 217347
If control falls off the end of a function after an __asm block, MSVC
assumes that the inline assembly filled the EAX and possibly EDX
registers with an appropriate return value. This functionality is used
in inline functions returning 64-bit integers in system headers, so we
need some amount of compatibility.
This is implemented in Clang by adding extra output constraints to every
inline asm block, and storing the resulting output registers into the
return value slot. If we see an asm block somewhere in the function
body, we emit a normal epilogue instead of marking the end of the
function with a return type unreachable.
Normal returns in functions not using this functionality will overwrite
the return value slot, and in most cases LLVM should be able to
eliminate the dead stores.
Fixes PR17201.
Reviewed By: majnemer
Differential Revision: http://reviews.llvm.org/D5177
llvm-svn: 217187
This avoids encoding information about the function prototype into the
thunk at the cost of some function prototype bitcast gymnastics.
Fixes PR20653.
llvm-svn: 216782
In C++11, instantiation of exception specs is deferred. The instantiation is
done in MarkFunctionReferenced(), which wasn't called for non-OdrUsed functions,
which then caused an assert in codegen. Fixes PR19190, see the bug for details.
llvm-svn: 216562
We would previously assert (a decl cannot have two DLL attributes) on this code:
template <typename T> struct __declspec(dllimport) S { T f() { return T(); } };
template struct __declspec(dllexport) S<int>;
The problem was that when instantiating, we would take the attribute from the
template even if the instantiation itself already had an attribute.
Also, don't inherit DLL attributes from the template to its members before
instantiation, as the attribute may change.
I couldn't figure out what MinGW does here, so I'm leaving that open. At least
we're not asserting anymore.
llvm-svn: 216340
This already works, but somewhat by accident (due to the order of
emission in clang, the location is set to the loop header (during the
emission of the iteratior increment) before the loop backedge is
emitted), so let's just add a test for symmetry and future-proofing.
llvm-svn: 216298
Similar to r215768 (which fixed the same case for while loops). To quote
r215768's commit message:
"A little test case simplification - this could be simplified further,
though there are certainly interesting connections to the if/else
construct so I'm hesitant to remove that entirely though it does appear
somewhat unrelated.
(similar fix to r215766, related to PR19864)"
llvm-svn: 216297
for loops introduce two scopes - one for the outer loop variable and its
initialization, and another for the body of the loop, including any
variable declared inside the loop condition.
llvm-svn: 216288
The Itanium ABI will give out the same mangling number for two different
lambdas if their call operators have different types. The MS ABI cannot
do the same because it does not mangle the return type into it's
lambdas.
This fixes PR20719.
llvm-svn: 216259
Normally we mark all members of exported classes referenced to get them emitted.
However, MSVC doesn't do this for class templates that are implicitly specialized or
just have an explicit instantiation declaration. For such specializations, the members
are emitted when referenced.
The exception is the case when the dllexport attribute is propagated from a base class
to a base class template that doesn't have an explicit attribute: in this case all
methods of the base class template do get instantiated.
llvm-svn: 216145
MSVC "14" CTP 3 has fixed it's mangling for alias templates when used as
template-template arguments; update clang to be compatible with this
mangling.
llvm-svn: 215972
This fixes PR20671, see the bug for details. In short, ActOnTranslationUnit()
calls DefineUsedVTables() and only then PerformPendingInstantiations(). But
PerformPendingInstantiations() is what does delayed template parsing, so
vtables only references from late-parsed templates weren't marked used.
As a fix, move the SavePendingInstantiationsAndVTableUsesRAII in
PerformPendingInstantiations() up above the delayed template parsing code.
That way, vtables referenced from templates end up in the RAII object, and the
call to DefineUsedVTables() in PerformPendingInstantiations() marks them used.
llvm-svn: 215786
A little test case simplification - this could be simplified further,
though there are certainly interesting connections to the if/else
construct so I'm hesitant to remove that entirely though it does appear
somewhat unrelated.
(similar fix to r215766, related to PR19864)
llvm-svn: 215768
This avoids debuggers stepping to strange places (like the last
statement in the loop body, or the first statement in the if).
This is not the whole answer, though - similar bugs no doubt exist in
other loops (patches to follow) and attributing exception handling code
to the correct line is also tricky (based on the previous fix to
PR19864, exception handling is still erroneously attributed to the 'if'
line).
llvm-svn: 215766
C++11 allows this qualifiers to exist on function types when used in
template arguments. Previously, I believed it wasn't possible because
MSVC rejected declarations like: S<int () const &> s;
However, it turns out MSVC properly allows them in using declarations;
updated clang to be compatible with this mangling.
llvm-svn: 215464
Previously, assigning an inheritance model to a derived class would
trigger further assiginments to the various bases of the class. This
was done to fix a bug where we couldn't handle an implicit
base-to-derived conversion for pointers-to-members when the conversion
was ambiguous at an earlier point.
However, this is not how the MS scheme works. Instead, assign
inheritance models to *just* the class which owns to declaration we
ended up referencing.
N.B. This result is surprising in many ways. It means that it is
possible for a base to have a "larger" inheritance model than it's
derived classes. It also means that bases in the conversion path do not
get assigned a model.
struct A { void f(); void f(int); };
struct B : A {};
struct C : B {};
void f() { void (C::*x)() = &A::f; }
We can only begin to assign an inheritance model *after* we've seen the
address-of but *before* we've done the implicit conversion the more
derived pointer-to-member type. After that point, both 'A' and 'C' will
have an inheritance model but 'B' will not. Surprising, right?
llvm-svn: 215174
There are no vtable offset offsets in the MS ABI, but vbtable offsets
are analogous. There are no consumers of this information yet, but at
least we don't crash now.
llvm-svn: 215149
This reverts commit r215137.
This doesn't work at all, an offset-offset is probably different than an
offset. I'm scared that this passed our normal test suite.
llvm-svn: 215141
It is possible for lambdas to get the same mangling number because they
may exist in different mangling contexts. To handle this correctly,
mangle the context into the name as well.
llvm-svn: 214947
The MS mangling scheme apparently has separate manglings for type and
non-type parameter packs when they are empty. Match template arguments
with parameters during mangling; check the parameter to see if it was
destined to hold type-ish things or nontype-ish things.
Differential Revision: http://reviews.llvm.org/D4792
llvm-svn: 214932
to instruct the code generator to not enforce a higher alignment
than the given number (of bytes) when accessing memory via an opaque
pointer or reference. Patch reviewed by John McCall (with post-commit
review pending). rdar://16254558
llvm-svn: 214911
This matches MSVC's logic, which seems to be that when the friend
declaration is qualified, it cannot be a declaration of a new symbol
and so the dll linkage doesn't change.
Differential Revision: http://reviews.llvm.org/D4764
llvm-svn: 214774
or a class derived from T. We already supported this when initializing
_Atomic(T) from T for most (and maybe all) other reasonable values of T.
llvm-svn: 214390
A templated using declaration may be used as a template-template
argument.
Unfortunately, the VS "14" chooses '?' as the sole marker for the
argument. This is problematic because it presupposes the possibility of
using more than one template-aliases as arguments to the same template.
This fixes PR20047.
llvm-svn: 214290
Rafael Espindola