r210637 regressed CodeGenCXX/mangle-ms-templates-memptrs.cpp because it
did not believe that there is a distinction between class templates and
function templates.
Sadly, there is. Function templates should behave in a compatible
manner with MSVC.
llvm-svn: 210642
Summary:
Previously, we would mangle nullptr pointer-to-member-functions in class
templates with a mangling we invented because contemporary versions of
MSVC would crash when trying to compile such code.
However, VS "14" can successfully compile these sorts of template
instantiations. This commit updates our mangling to be compatible with
theirs.
Reviewers: rnk
Reviewed By: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4059
llvm-svn: 210637
The backing store of thread local variables is internal for OS X and all
accesses must go through the thread wrapper.
However, individual TUs may have inlined through the thread wrapper.
To fix this, give the thread wrapper functions WeakAnyLinkage. This
prevents them from getting inlined into call-sites.
This fixes PR19989.
llvm-svn: 210632
expression of array-of-unknown-bound type, don't try to complete the array
bound, and return the alignment of the element type rather than 1.
llvm-svn: 210608
will never be true in a well-defined context. The checking for null pointers
has been moved into the caller logic so it does not rely on undefined behavior.
llvm-svn: 210498
Use mangled template instantiation name as key for back references.
Templates have their own context for back references, so their mangling
is always the same regardless of context. This avoids mangling template
instantiations twice.
Patch by Agustín Bergé!
llvm-svn: 210416
MSVC delays parsing of default arguments until instantiation. If the
default argument is never used, it is never parsed. We don't model
this.
Instead, if lookup of a type name fails in a template argument context,
we form a DependentNameType, which will be looked up at instantiation
time.
This fixes errors about 'CControlWinTraits' in atlwin.h.
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D3995
llvm-svn: 210382
Add driver and frontend support for the GCC -Wframe-larger-than=bytes warning.
This is the first GCC-compatible backend diagnostic built around LLVM's
reporting feature.
This commit adds infrastructure to perform reverse lookup from mangled names
emitted after LLVM IR generation. We use that to resolve precise locations and
originating AST functions, lambdas or block declarations to produce seamless
codegen-guided diagnostics.
An associated change, StringMap now maintains unique mangled name strings
instead of allocating copies. This is a net memory saving in C++ and a small
hit for C where we no longer reuse IdentifierInfo storage, pending further
optimisation.
llvm-svn: 210293
Straightforward implementation of UDLs, it's compatible with VS "14".
This nearly completes our implementation of C++ name mangling for the
MS-ABI.
llvm-svn: 210197
Also move the attribute-specific dumping to after dumping this and
the Implicit flag.
Differential Revision: http://reviews.llvm.org/D3971
llvm-svn: 209965
Summary:
This adds LambdaExpr::captures(), LambdaExpr::explicit_captures()
and LambdaExpr::implicit_captures() as simple wrappers over the underlying
*_begin()/*_end() functions.
Reviewers: aaron.ballman
Differential Revision: http://reviews.llvm.org/D3926
llvm-svn: 209679
A few (mostly CodeGen) parts of Clang were tightly coupled to the
AArch64 backend. Now that it's gone, they will not even compile.
I've also deduplicated RUN lines in many of the AArch64 tests. This
might improve "make check-all" time noticably: some of those NEON
tests were monsters.
llvm-svn: 209578
instead of before. The wrong order had no effect since Deallocate()
does nothing right now, but we may replace allocator in the future.
llvm-svn: 209567
Enables the emission of MS-compatible RTTI data structures for use with
typeid, dynamic_cast and exceptions. Does not implement dynamic_cast
or exceptions. As an artiface, typeid works in some cases but proper
support an testing will coming in a subsequent patch.
majnemer has fuzzed the results. Test cases included.
Differential Revision: http://reviews.llvm.org/D3833
llvm-svn: 209523
On test files I ran this on, memory consumption overall went down from
2.5G to 2G, without performance regressions.
I also investigated making DynTypedNode by itself smaller (by pulling
out pointers for everything that doesn't fit in 8 bytes). This led to
another 200-300MB saved, but also introduced a significant regression in
performance due to the memory management overhead.
llvm-svn: 209297
ensure that querying the first declaration for its most recent declaration
checks for redeclarations from the imported module.
This works as follows:
* The 'most recent' pointer on a canonical declaration grows a pointer to the
external AST source and a generation number (space- and time-optimized for
the case where there is no external source).
* Each time the 'most recent' pointer is queried, if it has an external source,
we check whether it's up to date, and update it if not.
* The ancillary data stored on the canonical declaration is allocated lazily
to avoid filling it in for declarations that end up being non-canonical.
We'll still perform a redundant (ASTContext) allocation if someone asks for
the most recent declaration from a decl before setPreviousDecl is called,
but such cases are probably all bugs, and are now easy to find.
Some finessing is still in order here -- in particular, we use a very general
mechanism for handling the DefinitionData pointer on CXXRecordData, and a more
targeted approach would be more compact.
Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was
addressing only a corner of the full problem space here. That's not covered
by this patch.
Early performance benchmarks show that this makes no measurable difference to
Clang performance without modules enabled (and fixes a major correctness issue
with modules enabled). I'll revert if a full performance comparison shows any
problems.
llvm-svn: 209046
GetGVALinkageForFunction handles TSK_ExplicitInstantiationDeclaration
twice, remove the redundant code trying to handle it again.
While we are here, update the reference we make to the standard. It
seems like another paragraph was added causing this text to get
renumbered.
llvm-svn: 208850
Implement what we currently believe is the mangling scheme for RTTI
data. Tests will be added in a later commit which actually generate
RTTI data.
llvm-svn: 208661
Summary:
Update our mangling to match the discussion on cxx-abi-dev.
This involves using a seq-id instead of an optional number.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3631
llvm-svn: 208140
Having various possible states of initialization following construction doesn't
add value here.
Also remove the unused size_reserve parameter.
llvm-svn: 207897
Summary:
Previously, we would generate a single name for all reference
temporaries and allow LLVM to rename them for us. Instead, number the
reference temporaries as we build them in Sema.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3554
llvm-svn: 207776
Since the community says that a blacklist is not good enough, and I don't have
enough time now to implement a proper whitelist, let's just remove the
attribute validation.
But, nevertheless, we can still communicate in the generated XML if our parser
found an issue with the HTML. But this bit is best-effort and is specifically
called out in the schema as such.
llvm-svn: 207712
It is possible that a variable template specialization might not have a
VisibilityAttr attached to it while the template that it specializes
does, in fact, have one.
We should consider the template in such cases.
This fixes PR19597.
llvm-svn: 207498
Summary:
A reference temporary should inherit the linkage of the variable it
initializes. Otherwise, we may hit cases where a reference temporary
wouldn't have the same value in all translation units.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3515
llvm-svn: 207451
We never aka vector types because our attributed syntax for it is less
comprehensible than the typedefs. This leaves the user in the dark when
the typedef isn't named that well.
Example:
v2s v; v4f w;
w = v;
The naming in this cases isn't even that bad, but the error we give is
useless without looking up the actual typedefs.
t.c:6:5: error: assigning to 'v4f' from incompatible type 'v2s'
Now:
t.c:6:5: error: assigning to 'v4f' (vector of 4 'float' values) from
incompatible type 'v2s' (vector of 2 'int' values)
We do this for all diagnostics that print a vector type.
llvm-svn: 207267
through to the output even if the input comment comes from an untrusted source
Attribute filtering is currently based on a blacklist, which right now includes
all event handler attributes (they contain JavaScipt code). It should be
switched to a whitelist, but going over all of the HTML5 spec requires a
significant amount of time.
llvm-svn: 206882
When instantiating an array that has an alignment attribute on it, we
were looking through the array type and only considering the element
type for the resulting alignment. We need to make sure we take the
array's requirements into account too.
llvm-svn: 206317
Previously, it was believed that #pragma vtordisp(0) would prohibit the
generation of any and all vtordisps.
In actuality, it only disables the generation of additional vtordisps.
This fixes PR19413.
llvm-svn: 206124
A portion of the vtordisp computation that was previously unguarded by a
test for the declaration of user defined constructors/destructors was
erroniously adding vtordisps to things that shouldn't have them. This
patch correctly guards that codepath. In addition, it updates the
comments to make them more clear. Test case is included.
llvm-svn: 206077
This patch updates the comments in RecordLayoutBuilder about record
layout in the MS-ABI. Also, I added a section about known
incompatibilities.
llvm-svn: 206010
In version 9 (VS2010) (and prior)? versions of msvc, if the last field
in a record was a bitfield padding equal to the size of the storage
class of that bitfield was added before each vbase and vtordisp. This
patch removes that feature from clang and updates the lit tests to
reflect it.
llvm-svn: 206004
The vbptr is injected after the last non-virtual base lexographically
rather than the last non-virtual base in layout order. Test case
included. Also, some line ending fixes.
llvm-svn: 206000
When __declspec(align()) is applied to a bitfield it affects the
alignment rather than the required alignment of the struct. The major
feature that this patch adds is that the alignment of the structure
obeys the alignment of __declspec(align()) from the bitfield over the
value specified in pragma pack.
Test cases are included.
The patch also includes some small cleanups in recordlayoutbuilder and
some cleanups to some lit tests, including line endings (but no
functionality change to lit tests)
llvm-svn: 205994
cxx-abi-dev came up with a way to disambiguate between different
keywords used in elaborated type specifiers.
This resolves certain collisions during mangling.
llvm-svn: 205943
This patch changes how we determine if padding is needed between two
bases in msvc compatibility mode. Test cases included.
In addition, a very minor change to the printing of structures to ease
lit testing.
llvm-svn: 205933
It is very similar to GCC's __PRETTY_FUNCTION__, except it prints the
calling convention.
Reviewers: majnemer
Differential Revision: http://reviews.llvm.org/D3311
llvm-svn: 205780
This can actually be non-zero if you override a function from a virtual
base and you have forced the most_general pointer to member
representation.
llvm-svn: 205727
better. This warning will now trigger on the following conditionals:
bool b;
int i;
if (b > 1) {} // always false
if (0 <= (i > 5)) {} // always true
if (-1 > b) {} // always false
Patch by Per Viberg.
llvm-svn: 205608
No functionality change.
When determining the pattern for instantiating a generic lambda call operator specialization - we must not go drilling down for the 'prototype' (i.e. as written) pattern - rather we must use our partially transformed pattern (whose DeclRefExprs are wired correctly to any enclosing lambda's decls that should be mapped correctly in a local instantiation scope) that is the templated pattern of the specialization's primary template (even though the primary template might be instantiated from a 'prototype' member-template). Previously, the drilling down was haltted by marking the instantiated-from primary template as a member-specialization (incorrectly).
This prompted Richard to remark (http://llvm-reviews.chandlerc.com/D1784?id=4687#inline-10272)
"It's a bit nasty to (essentially) set this bit incorrectly. Can you put the check into getTemplateInstantiationPattern instead?"
In my reckless youth, I chose to ignore that comment. With the passage of time, I have come to learn the value of bowing to the will of the angry Gods ;)
llvm-svn: 205543
Summary:
MSVC always emits inline functions marked with the extern storage class
specifier. The result is something similar to the opposite of
__attribute__((gnu_inline)).
This extension is also available in C.
This fixes PR19264.
Reviewers: rnk, rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3207
llvm-svn: 205485
For namespaces, this is consistent with mangling and GCC's debug info
behavior. For structs, GCC uses <anonymous struct> but we prefer
consistency between all anonymous entities but don't want to confuse
them with template arguments, etc, so we'll just go with parens in all
cases.
llvm-svn: 205398
While investigating some debug info issues, Eric and I came across a
particular template case where the location of a decl was quite
different from the range of the same decl. It might've been rather
helpful if the dumper had actually showed us this.
llvm-svn: 205396
The MS ABI forces us into catch-22 when it comes to functions which
return types which are local:
- A function is mangled with it's return type.
- A type is mangled with it's surrounding context.
Avoid this by mangling auto and decltype(autp) directly into the
function's return type. Using this mangling has the double advantage of
being compatible with the C++ standard without crashing the compiler.
N.B. For the curious, the MSVC mangling leads to collisions amongst
template functions and either crashes when faced with local types or is
otherwise incapable of returning them.
llvm-svn: 205282
It turns out that the ranges where the '?' <letter> manglings occur are
identical to the ranges of ASCII characters OR'd with 0x80.
Thanks to Richard Smith for the insight!
No functional change.
llvm-svn: 205270
The delta between '\xe1' and '\xc1' is equivalent to the one between 'a'
and 'A'. This allows us to reuse the computation between '\xe1' and
'\xfa' for the '\xc1' to '\xda' case.
No functionality change.
llvm-svn: 205128
This adds Clang support for the ARM64 backend. There are definitely
still some rough edges, so please bring up any issues you see with
this patch.
As with the LLVM commit though, we think it'll be more useful for
merging with AArch64 from within the tree.
llvm-svn: 205100
This follows the LLVM change to canonicalise the Windows target triple
spellings. Rather than treating each Windows environment as a single entity,
the environments are now modelled properly as an environment. This is a
mechanical change to convert the triple use to reflect that change.
llvm-svn: 204978
correctly order comments in SourceManager::isBeforeInTranslationUnit() order
Unfortunately, this is not as simple as it was implemented previously, and
actually requires doing a merge sort.
llvm-svn: 204936
Store the number of clauses and children of OMPExecutableDirective and dynamically compute the locations of corresponding arrays.
http://llvm-reviews.chandlerc.com/D2977
llvm-svn: 204933
COFF doesn't have mergeable sections so LLVM/clang's normal tactics for
string deduplication will not have any effect.
To remedy this we place each string inside it's own section and mark
the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the
string has an external name that we can generate from it's contents.
To be compatible with MSVC, we must use their scheme. Otherwise identical
strings in translation units from clang may not be deduplicated with
translation units in MSVC.
This fixes PR18248.
N.B. We will not attempt to do anything with a string literal which is not of
type 'char' or 'wchar_t' because their compiler does not support unicode
string literals as of this date. Further, we avoid doing this if
either -fwritable-strings or -fsanitize=address are present.
This reverts commit r204596.
llvm-svn: 204675
As of cl.exe version 18, the special layout rules for structs with
alignment 16 or greater has been dropped. This patch drops the behavior
from clang. This patch also updates the lit tests to reflect the
change.
llvm-svn: 204674
This commit cleans up a few accidents:
- Do not rely on the order in which StringLiteral lays out bytes.
- Use a more efficient mechanism for handling so-called
"special-mappings" when mangling string literals.
- There is no need to allocate a copy of the mangled name.
- Add the test written for r204562.
Thanks to Richard Smith for pointing these out!
llvm-svn: 204586
COFF doesn't have mergeable sections so LLVM/clang's normal tactics for
string deduplication will not have any effect.
To remedy this we place each string inside it's own section and mark
the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the
string has an external name that we can generate from it's contents.
To be compatible with MSVC, we must use their scheme. Otherwise identical
strings in translation units from clang may not be deduplicated with
translation units in MSVC.
This fixes PR18248.
N.B. We will not attempt to do anything with a string literal which is not of
type 'char' or 'wchar_t' because their compiler does not support unicode
string literals as of this date.
llvm-svn: 204562
Since "half" is an OpenCL keyword and clang accepts __fp16 as an extension for
other languages, error messages and metadata (and hence debug info) should refer
to the half-precision floating point as "__fp16" instead of "half" when
compiling for non-OpenCL languages. This patch creates a new printing policy for
half in a similar manner to what is done for bool and wchar_t.
Differential Revision: http://llvm-reviews.chandlerc.com/D2952
llvm-svn: 204164
Summary:
Gracefully fail to evaluate a constant expression if its type is
unknown, rather than failing an assertion trying to access the type.
Reviewers: klimek
Reviewed By: klimek
CC: chandlerc, cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3075
llvm-svn: 203950
Drive-by fixing some incorrect types where a for loop would be improperly using ObjCInterfaceDecl::protocol_iterator. No functional changes in these cases.
llvm-svn: 203842
This is a reapplication of r203236 with modifications to the definition of attrs() and following the new style guidelines on auto usage.
llvm-svn: 203362
This changes the iterators so that they are no longer implemented in terms of ranges (so it's a very partial revert of the existing rangification efforts).
llvm-svn: 203299
David Majnemer