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
David Majnemer