At this point, it's clear that the MSVC mangler uses the type-as-written
instead of the canonical type, so this should bring us closer to MSVC.
The main thrust of this change is to fix the way we mangle decayed array
parameters of function pointer parameters. With a DecayedType sugar
node, this code can now be much simpler.
Fixes PR16096.
This also fixes a separate issue that Richard spotted in review.
Because separate declarations of the same entity can be spelled and
mangled differently, MSVC always mangles the earliest declaration in an
attempt to avoid link errors. Clang now does the same.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D844
llvm-svn: 184777
There's still a problem here - since we're not appropriately using the
signedness/range of the enum to chooset the encoding and emission of
enumerators, but GCC has some bugs around this too so I assume that's
not /such/ a high priority though I may get to it soon out of
completeness.
llvm-svn: 184695
Empty structs are ignored for parameter passing purposes, but va_arg was
incrementing the pointer anyway which could lead to va_list getting out of
sync.
llvm-svn: 184605
According to the Itanium ABI (3.1.1), types with non-trivial copy constructors
passed by value should be passed indirectly, with the caller creating a
temporary.
We got this mostly correct, but forgot that empty structs can have non-trivial
constructors too and passed them incorrectly. This simply reverses the order of
the check.
llvm-svn: 184603
Itanium destroys them in the caller at the end of the full expression,
but MSVC destroys them in the callee. This is further complicated by
the need to emit EH-only destructor cleanups in the caller.
This should help clang compile MSVC's debug iterators more correctly.
There is still an outstanding issue in PR5064 of a memcpy emitted by the
LLVM backend, which is not correct for C++ records.
Fixes PR16226.
Reviewers: rjmccall
Differential Revision: http://llvm-reviews.chandlerc.com/D929
llvm-svn: 184543
This is to make test cases looking for definitions more legible by
making the definition explicit rather than just the absence of '[fwd]'.
This allowed the debug-info-record tests to be rephrased - and in the
interests of reducing the number of individual test cases/invocations we
have, I merged them into one file, separated them with namespaces (&
then moved them to C++ because namespaces are great). If they need to
remain 'C' only tests, they can be moved back. (I didn't group them with
'debug-info-class.cpp' because these tests only apply to
-fno-limit-debug-info)
I removed the pieces of code that would cause these tests to pass under
-flimit-debug-info to ensure the tests remain relevant to their fixes
should we ever improve -flimit-debug-info to catch that kind of code.
This commit is version locked with the corresponding change to
DebugInfo.h in LLVM. Except some transient buildbot fallout.
llvm-svn: 184524
r174939-40 caused us to do this in the canonical terminate lpad,
but when the EH stack has other cleanups on it we use the
terminate handler block, which wasn't doing this.
Fixes the rest of rdar://11904428 given appropriate stdlib support.
llvm-svn: 184475
On Windows, it looks like FlagIndirectVariable is being set in Flags for
DIBuilder::createLocalVariable(), giving us an i32 of 8192 instead of 0,
as on Linux.
Fixes breakage from r184367.
llvm-svn: 184438
This is to fix the location information for such parameters to refer to
the object accessible through the pointer rather than to the pointer
parameter itself.
llvm-svn: 184367
1) Removed useless return value of CGCXXABI::EmitConstructorCall and CGCXXABI::EmitVirtualDestructorCall and implementations
2) Corrected last portion of CodeGenCXX/constructor-destructor-return-this to correctly test for non-'this'-return of virtual destructor calls
llvm-svn: 184330
In Itanium, dynamic classes have one vtable with several different
address points for dynamic base classes that can't share vtables.
In the MS C++ ABI, each vbtable that can't be shared gets its own
symbol, similar to how ctor vtables work in Itanium. However, instead
of mangling the subobject offset into the symbol, the unique portions of
the inheritance path are mangled into the symbol to make it unique.
This patch implements the MSVC 2012 scheme for forming unique vbtable
symbol names. MSVC 2010 use the same mangling with a different subset
of the path. Implementing that mangling and possibly others is TODO.
Each vbtable is an array of i32 offsets from the vbptr that points to it
to another virtual base subobject. The first entry of a vbtable always
points to the base of the current subobject, implying that it is the
same no matter which parent class contains it.
Reviewers: rjmccall
Differential Revision: http://llvm-reviews.chandlerc.com/D636
llvm-svn: 184309
The backend will now use the generic 'returned' attribute to form tail calls where possible, as well as avoid save-restores of 'this' in some cases (specifically the cases that matter for the ARM C++ ABI).
This patch also reverts a prior front-end only partial implementation of these optimizations, since it's no longer required.
llvm-svn: 184205
the result of a cast-to-reference-type lifetime-extends the object to which the
reference inside the cast binds.
This requires us to look for subobject adjustments on both the inside and the
outside of the MaterializeTemporaryExpr when looking for a temporary to
lifetime-extend (which we also need for core issue 616, and possibly 1213).
llvm-svn: 184024
Introduce CXXStdInitializerListExpr node, representing the implicit
construction of a std::initializer_list<T> object from its underlying array.
The AST representation of such an expression goes from an InitListExpr with a
flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr
containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr).
This more detailed representation has several advantages, the most important of
which is that the new MaterializeTemporaryExpr allows us to directly model
lifetime extension of the underlying temporary array. Using that, this patch
*drastically* simplifies the IR generation of this construct, provides IR
generation support for nested global initializer_list objects, fixes several
bugs where the destructors for the underlying array would accidentally not get
invoked, and provides constant expression evaluation support for
std::initializer_list objects.
llvm-svn: 183872
were lacking ExprWithCleanups nodes in some cases where the new approach to
lifetime extension needed them).
Original commit message:
Rework IR emission for lifetime-extended temporaries. Instead of trying to walk
into the expression and dig out a single lifetime-extended entity and manually
pull its cleanup outside the expression, instead keep a list of the cleanups
which we'll need to emit when we get to the end of the full-expression. Also
emit those cleanups early, as EH-only cleanups, to cover the case that the
full-expression does not terminate normally. This allows IR generation to
properly model temporary lifetime when multiple temporaries are extended by the
same declaration.
We have a pre-existing bug where an exception thrown from a temporary's
destructor does not clean up lifetime-extended temporaries created in the same
expression and extended to automatic storage duration; that is not fixed by
this patch.
llvm-svn: 183859
into the expression and dig out a single lifetime-extended entity and manually
pull its cleanup outside the expression, instead keep a list of the cleanups
which we'll need to emit when we get to the end of the full-expression. Also
emit those cleanups early, as EH-only cleanups, to cover the case that the
full-expression does not terminate normally. This allows IR generation to
properly model temporary lifetime when multiple temporaries are extended by the
same declaration.
We have a pre-existing bug where an exception thrown from a temporary's
destructor does not clean up lifetime-extended temporaries created in the same
expression and extended to automatic storage duration; that is not fixed by
this patch.
llvm-svn: 183721
Two variables with the same name declared in two if conditions in the same
scope are no longer coalesced into one.
rdar://problem/14024005
llvm-svn: 183597
There seems to have been some erroneous code attempting to describe the
ABI of parameters (non-trivial record parameters are passed by
reference). This would break the type of the function (especially when
it caused a mismatch between the type of a declaration & a definition)
causing PR14763 and PR14645.
llvm-svn: 183329
Also addresses a review comment from John from on r180985 by removing
the "== -1" check, since it's now reusing the correct code which has the
comment.
llvm-svn: 183318
In an effort to make -flimit-debug-info more consistent I over-shot the
mark & made types used via typedefs never produce definitions in the
debug info (even if the type was used in a way that would require a
definition).
The fix for this is to do exactly what I was hoping to do at some point
- plumb the declaration/definition choice through the various layers of
"CreateType" in CGDebugInfo. In this way we can produce declarations
whenever they are sufficient & definitions otherwise - including when
qualifiers are used, for example (discovered in PR14467). This may not
be complete (there may be other types/situations where we need to
propagate the "declaration/definition" choice) but it lays the basic
foundation which we can enhance in future iterations.
llvm-svn: 183296
handle temporaries which have been lifetime-extended to static storage duration
within constant expressions. This correctly handles nested lifetime extension
(through reference members of aggregates in aggregate initializers) but
non-constant-expression emission hasn't yet been updated to do the same.
llvm-svn: 183283
Template functions (and member functions of class templates) present the same
problem as inline functions. They need to be uniqued, so we need to assign
VisibleNoLinkage linkage to types defined in them.
llvm-svn: 183222
which is lifetime-extended by a reference binding. An additional temporary is
created for such a bitfield access (although we have no explicit AST
representation for it).
llvm-svn: 183095
clang would incorrectly not allow the following:
int x = true ? (throw 1) : 2;
The problem exists because we don't see beyond the parens.
This, in turn, causes us to believe that we are choosing between void
and int which we diagnose as an error.
Instead, allow clang to see the 'throw' inside the parens.
llvm-svn: 183085
syntactic form in template instantiation. Previously, this blocked the
reversion and we ended up losing inner CXXBindTemporaryExprs (and thus
forgetting to call destructors!).
llvm-svn: 182969
While we can't yet emit vbtables, this allows us to find virtual bases
of objects constructed in other TUs.
This make iostream hello world work, since basic_ostream virtually
inherits from basic_ios.
Differential Revision: http://llvm-reviews.chandlerc.com/D795
llvm-svn: 182870
MSVC's class data is always comdat, so clang's should always be
linkonce_odr in LLVM IR.
Reviewers: pcc
Differential Revision: http://llvm-reviews.chandlerc.com/D838
llvm-svn: 182865
John noticed that the fix for pr15930 (r181981) didn't handle indirect
uses of local types. For example, a pointer to local struct, or a
function that returns it.
One way to implement this would be to recursively look for local
types. This would look a lot like the linkage computation itself for
types.
To avoid code duplication and utilize the existing linkage cache, this
patch just makes the computation of "type with no linkage but
externally visible because it is from an inline function" part of the
linkage computation itself.
llvm-svn: 182711
Perhaps we should just suppress this, rather than erroring, but since we
have the infrastructure for it I figured I'd use it - if this is
determined to be not the right thing we should probably remove that
infrastructure entirely. I guess it's lying around from the early days
of implementing debug info support.
llvm-svn: 182673
This resolves the last of the PR14606 failures in the GDB 7.5 test
suite. (but there are still unresolved issues in the imported_decl case
- we need to implement optional/lazy decls for functions & variables
like we already do for types)
llvm-svn: 182329
This reverts commit r181947 (git d2990ce56a16050cac0d7937ec9919ff54c6df62 )
This addresses one of the two issues identified in r181947, ensuring
that types imported via using declarations only result in a declaration
being emitted for the type, not a definition. The second issue (emitting
using declarations that are unused) is hopefully an acceptable increase
as the real fix for this would be a bit difficult (probably at best we
could record which using directives were involved in lookups - but may
not have been the result of the lookup).
This also ensures that DW_TAG_imported_declarations (& directives) are
not emitted in line-tables-only mode as well as ensuring that typedefs
only require/emit declarations (rather than definitions) for referenced
types.
llvm-svn: 182231
In the case of inline functions, we have to special case local types
when they are used as template arguments to make sure the template
instantiations are still uniqued in case the function itself is inlined.
llvm-svn: 181981
This reverts commit r181393 (git 3923d6a87fe7b2c91cc4a7dbd90c4ec7e2316bcd).
This seems to be emitting too much extra debug info for two (known)
reasons:
* full class definitions are emitted when only declarations are expected
* unused using declarations still produce DW_TAG_imported_declarations
llvm-svn: 181947
Most of the complexity of this patch is figuring out which types get the
qualifier and which don't. If we implement __ptr32/64, then we should
check the qualifier instead of assuming all pointers are 64-bit.
This fixes PR13792.
Patch by Warren Hunt!
llvm-svn: 181825
We might benefit from API refactoring here (why pass in a value that's
derived from another parameter?) but this is the immediate issue.
llvm-svn: 181747
Generalize some attributes that differ on powerpc64 (i32 vs signext i32). Also
fix some copy-and-pasted code that didn't get updated properly.
llvm-svn: 181707
type returns a lambda defined within itself. The computation of linkage for the
function looked at the linkage of the lambda, and vice versa.
This is solved by not checking whether an 'auto' in a function return type
deduces to a type with unique external linkage. We don't need this check,
because the type deduced for 'auto' doesn't affect whether two
otherwise-identical declarations would name different functions, so we don't
need to give an ostensibly external-linkage function internal linkage for this
reason. (We also don't need unique-external linkage in C++11 onwards at all,
but that's not implemented yet.)
llvm-svn: 181675
We could support the GCC extension DW_TAG_GNU_template_parameter_pack if
we're feeling adventurous, at some point - but I don't think GDB's doing
anything useful with it yet anyway.
llvm-svn: 181644
* Provide DW_TAG_template_value_parameter for pointers, function
pointers, member pointers, and member function pointers (still missing
support for template template parameters which GCC encodes as a
DW_TAG_GNU_template_template_param)
* Provide values for all but the (member & non-member) function pointer case.
Simple constant integer values for member pointers (offset within the
object) and address for the value pointer case. GCC doesn't provide a
value for the member function pointer case so I'm not sure how, if at
all, GDB supports encoding that. & non-member function pointers should
follow shortly in a subsequent patch.
* Null pointer value encodings of all of these types, including
correctly encoding null data member pointers as -1.
llvm-svn: 181634
for C++ constructors.
If the DIType for a class was generated by
CGDebugInfo::createContextChain(), the cache contains only a
limited DIType wihtout any declarations. Since EmitFunctionStart()
needs to find the canonical declaration for each method, we
construct the complete type before emitting any method.
rdar://problem/13116508
llvm-svn: 181561
This fixes several (7 out of 16) cases of PR14492 in the GDB 7.5 test
suite. It seems GDB was bailing out whenever it had even the slightest
problem with the template argument list (& I assume it didn't like
seeing template value parameters that were just simple names - perhaps
assuming that lone names must be types, not values)
llvm-svn: 181556
Both these tests were ultimately fixed by the check for
"isIncompleteType" & neither test case was really reduced to a minimal
form. On doing so it becomes apparent that the problem wasn't specific
to templates at all, so I've moved the test case to a more appropriate
test file and added FileCheck verification to it (to show the forward
declaration of the array element type as well as the array alignment and
size being 0 since it cannot be computed). That's about as far down this
rabbithole as I'm willing to go today, so the rest of the un-FileChecked
tests in test/CodeGenCXX/debug-info.cpp will have to go another day
without actually testing anything other than the fact that they don't
crash.
& improve the actually interesting test case in
test/CodeGenCXX/debug-info-templates.cpp which was my original goal (in
preparation for expanding it/fixing some related bugs in non-type
template parameters)
llvm-svn: 181552
Summary:
This only supports converting along non-virtual inheritance paths by
changing the field offset or the non-virtual base adjustment.
This implements three kinds of conversions:
- codegen for Value conversions
- Constant emission for APValue
- Constant folding for CastExprs
In almost all constant initialization settings
EmitMemberPointer(APValue) is called, except when the expression
contains a reinterpret cast.
reinterpret casts end up being a big corner case because the null value
changes between different kinds of member pointers.
Reviewers: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D741
llvm-svn: 181543
EmitCapturedStmt creates a captured struct containing all of the captured
variables, and then emits a call to the outlined function. This is similar in
principle to EmitBlockLiteral.
GenerateCapturedFunction actually produces the outlined function. It is based
on GenerateBlockFunction, but is much simpler. The function type is determined
by the parameters that are in the CapturedDecl.
Some changes have been added to this patch that were reviewed as part of the
serialization patch and moving the parameters to the captured decl.
Differential Revision: http://llvm-reviews.chandlerc.com/D640
llvm-svn: 181536
object x, x's subobjects can be constructed by constexpr constructor even if
they are of non-literal type, and can be read and written even though they're
not members of a constexpr object or temporary.
llvm-svn: 181506
Basic support is implemented here - it still doesn't account for
declared-but-not-defined variables or functions. It cannot handle out of
order (declared, 'using', then defined) cases for variables, but can
handle that for functions (& can handle declared, 'using'd, and not
defined at all cases for types).
llvm-svn: 181393
unnamed bitfields.
Unnamed bitfields won't have an explicit copy operation
in the AST, which breaks the strong form of the invariant.
rdar://13816940
llvm-svn: 181289
David Majnemer