FunctionProtoType::ExtProtoInfo. Most of the users of these fields don't care
about the other ExtProtoInfo bits and just want to talk about the exception
specification.
llvm-svn: 214450
Iterator invalidation issues already force us to do one lookup and one
insert.
Don't use the particular bit-pattern of the 'Align' field to determine
whether or not we have already inserted into the TypeInfo DenseMap;
instead ask for an iterator to the TypeInfo entry.
llvm-svn: 214293
The MS ABI has a notion of 'required alignment' for fields; this
alignment supercedes pragma pack directives.
MSVC takes into account alignment attributes on typedefs when
determining whether or not a field has a certain required alignment.
Do the same in clang by tracking whether or not we saw such an attribute
when calculating the type's bitwidth and alignment.
This fixes PR20418.
Reviewers: rnk
Differential Revision: http://reviews.llvm.org/D4714
llvm-svn: 214274
This makes us emit dllexported in-class initialized static data members (which
are treated as definitions in MSVC), even when they're not referenced.
It also makes their special linkage reflected in the GVA linkage instead of
getting massaged in CodeGen.
Differential Revision: http://reviews.llvm.org/D4563
llvm-svn: 213304
Summary:
Do not store duplicate parents when memoization data is available.
This does not solve the duplication problem, but ameliorates it.
Reviewers: klimek
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D4124
llvm-svn: 210902
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
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
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
Having various possible states of initialization following construction doesn't
add value here.
Also remove the unused size_reserve parameter.
llvm-svn: 207897
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
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
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
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
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
Summary:
The MSVC ABI appears to mangle the lexical scope into the names of
statics. Specifically, a counter is incremented whenever a scope is
entered where things can be declared in such a way that an ambiguity can
arise. For example, a class scope inside of a class scope doesn't do
anything interesting because the nested class cannot collide with
another nested class.
There are problems with this scheme:
- It is unreliable. The counter is only incremented when a previously
never encountered scope is entered. There are cases where this will
cause ambiguity amongst declarations that have the same name where one
was introduced in a deep scope while the other was introduced right
after in the previous lexical scope.
- It is wasteful. Statements like: {{{{{{{ static int foo = a; }}}}}}}
will make the mangling of "foo" larger than it need be because the
scope counter has been incremented many times.
Because of these problems, and practical implementation concerns. We
choose not to implement this scheme if the local static or local type
isn't visible. The mangling of these declarations will look very
similar but the numbering will make far more sense, this scheme is
lifted from the Itanium ABI implementation.
Reviewers: rsmith, doug.gregor, rnk, eli.friedman, cdavis5x
Reviewed By: rnk
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2953
llvm-svn: 202951
With r197755 we started reading the contents of buffer file entries, but the
buffers may point to ASTReader blobs that have been disposed.
Fix this by having the CompilerInstance object keep a reference to the ASTReader
as well as having the ASTContext keep reference to the ExternalASTSource.
This was very difficult to construct a test case for.
rdar://16149782
llvm-svn: 202346
When calculating the preferred alignment of a type, consider if a alignment
attribute came from a typedef declaration. If one did, do not naturally align
the type.
Patch by Stephan Tolksdorf, with a little tweaking and an additional testcase by me.
llvm-svn: 202088
Most 64-bit targets define int64_t as long int, and AArch64 should
make same definition to follow LP64 model. In GNU tool chain, int64_t
is defined as long int for 64-bit target. So to get consistent with GNU,
it's better Changing int64_t from 'long long int' to 'long int',
otherwise clang will get different name mangling suffix compared with g++.
llvm-svn: 202004
Member pointers are mangled as they would be represented at runtime.
They can be a single integer literal, single decl, or a tuple with some
more numbers tossed in. With Clang today, most of those numbers will be
zero because we reject pointers to members of virtual bases.
This change required moving VTableContextBase ownership from
CodeGenVTables to ASTContext, because mangling now depends on vtable
layout.
I also hoisted the inheritance model helpers up to be inline static
methods of MSInheritanceAttr. This makes the AST code that deals with
member pointers much more readable.
MSVC doesn't appear to have stable manglings of null member pointers:
- Null data memptrs in function templates have a mangling collision with
the first field of a non-polymorphic single inheritance class.
- The mangling of null data memptrs changes if you add casts.
- Large null function memptrs in class templates crash MSVC.
Clang uses the class template mangling for null data memptrs and the
function template mangling for null function memptrs to deal with this.
Reviewers: majnemer
Differential Revision: http://llvm-reviews.chandlerc.com/D2695
llvm-svn: 200857
A return type is the declared or deduced part of the function type specified in
the declaration.
A result type is the (potentially adjusted) type of the value of an expression
that calls the function.
Rule of thumb:
* Declarations have return types and parameters.
* Expressions have result types and arguments.
llvm-svn: 200082
not using backing ivar warning, ignore when
property is not being synthesized (user declared its
implementation @dynamic). // rdar://1583425
llvm-svn: 199820
Fix a perennial source of confusion in the clang type system: Declarations and
function prototypes have parameters to which arguments are supplied, so calling
these 'arguments' was a stretch even in C mode, let alone C++ where default
arguments, templates and overloading make the distinction important to get
right.
Readability win across the board, especially in the casting, ADL and
overloading implementations which make a lot more sense at a glance now.
Will keep an eye on the builders and update dependent projects shortly.
No functional change.
llvm-svn: 199686
There's been long-standing confusion over the role of these two options. This
commit makes the necessary changes to differentiate them clearly, following up
from r198936.
MicrosoftExt (aka. fms-extensions):
Enable largely unobjectionable Microsoft language extensions to ease
portability. This mode, also supported by gcc, is used for building software
like FreeBSD and Linux kernel extensions that share code with Windows drivers.
MSVCCompat (aka. -fms-compatibility, formerly MicrosoftMode):
Turn on a special mode supporting 'heinous' extensions for drop-in
compatibility with the Microsoft Visual C++ product. Standards-compilant C and
C++ code isn't guaranteed to work in this mode. Implies MicrosoftExt.
Note that full -fms-compatibility mode is currently enabled by default on the
Windows target, which may need tuning to serve as a reasonable default.
See cfe-commits for the full discourse, thread 'r198497 - Move MS predefined
type_info out of InitializePredefinedMacros'
No change in behaviour.
llvm-svn: 199209
__builtin_va_list and friends have been showing up where they shouldn't for way
to long, making unwanted appearences in -ast-print, tooling and source level
visitors and even the hello world tutorial on the clang website.
This commit factors down the implicit typedef and record creation facilities to
ensure they're marked implicit.
Also fixes a unit test that was testing incorrect behaviour, and removes old
hacks in the DeclPrinter that tried to skip implicit declarations manually.
llvm-svn: 197336
Summary:
In general, this type node can be used to represent any type adjustment
that occurs implicitly without losing type sugar. The immediate use of
this is to adjust the calling conventions of member function pointer
types without breaking template instantiation.
Fixes PR17996.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D2332
llvm-svn: 196451
The xcore llvm backend does not handle 8 byte alignment viz:
"%BadAlignment = alloca i64, align 8"
So getPreferredTypeAlign() must never overalign.
llvm-svn: 194462
Differential Revision: http://llvm-reviews.chandlerc.com/D2090
Clang was "improperly" over-aligning arrays with sizes are not a multiple of
their alignment.
This behavior was removed in microsoft 32 bit mode.
In addition, after examination of ASTContext::getTypeInfoImpl, a redundant code block in
MicrosoftRecordLayoutBuilder::getAdjustedFieldInfo was deleted.
llvm-svn: 193898
address spaces which is both (1) a "semantic" concept and
(2) possibly a hardware level restriction. It is desirable to
be able to discard/merge the LLVM-level address spaces on arguments for which
there is no difference to the current backend while keeping
track of the semantic address spaces in a funciton prototype. To do this
enable addition of the address space into the name-mangling process. Add
some tests to document this behaviour against inadvertent changes.
Patch by Michele Scandale!
llvm-svn: 190684
Static locals requiring initialization are not thread safe on Windows.
Unfortunately, it's possible to create static locals that are actually
externally visible with inline functions and templates. As a result, we
have to implement an initialization guard scheme that is compatible with
TUs built by MSVC, which makes thread safety prohibitively difficult.
MSVC's scheme is that every function that requires a guard gets an i32
bitfield. Each static local is assigned a bit that indicates if it has
been initialized, up to 32 bits, at which point a new bitfield is
created. MSVC rejects inline functions with more than 32 static locals,
and the externally visible mangling (?_B) only allows for one guard
variable per function.
On Eli's recommendation, I used MangleNumberingContext to track which
bit each static corresponds to.
Implements PR16888.
Reviewers: rjmccall, eli.friedman
Differential Revision: http://llvm-reviews.chandlerc.com/D1416
llvm-svn: 190427
getRealTypeByWidth and getIntTypeByWidth
for ASTContext names are almost same(invokes new methods from TargetInfo):
getIntTypeForBitwidth and getRealTypeForBitwidth.
As first commit for PR16752 fix: 'mode' attribute for unusual targets doesn't work properly
Description:
Troubles could be happened due to some assumptions in handleModeAttr function (see SemaDeclAttr.cpp).
For example, it assumes that 32 bit integer is 'int', while it could be 16 bit only.
Instead of asking target: 'which type do you want to use for int32_t ?' it just hardcodes general opinion. That doesn't looks pretty correct.
Please consider the next solution:
1. In Basic/TargetInfo add getIntTypeByWidth and getRealTypeByWidth virtual methods. By default current behaviour could be implemented here.
2. Fix handleModeAttr according to new methods in TargetInfo.
This approach is implemented in the patch attached to this post.
Fixes:
1st Commit (Current): Add new methods for TargetInfo:
getRealTypeByWidth and getIntTypeByWidth
for ASTContext names are almost same(invokes new methods from TargetInfo):
getIntTypeForBitwidth and getRealTypeForBitwidth
2nd Commit (Next): Fix SemaDeclAttr, handleModeAttr function.
llvm-svn: 190044
Summary:
Makes functions with implicit calling convention compatible with
function types with a matching explicit calling convention. This fixes
things like calls to qsort(), which has an explicit __cdecl attribute on
the comparator in Windows headers.
Clang will now infer the calling convention from the declarator. There
are two cases when the CC must be adjusted during redeclaration:
1. When defining a non-inline static method.
2. When redeclaring a function with an implicit or mismatched
convention.
Fixes PR13457, and allows clang to compile CommandLine.cpp for the
Microsoft C++ ABI.
Excellent test cases provided by Alexander Zinenko!
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D1231
llvm-svn: 189412
Specifically, the following features are not included in this commit:
- any sort of capturing within generic lambdas
- nested lambdas
- conversion operator for captureless lambdas
- ensuring all visitors are generic lambda aware
As an example of what compiles:
template <class F1, class F2>
struct overload : F1, F2 {
using F1::operator();
using F2::operator();
overload(F1 f1, F2 f2) : F1(f1), F2(f2) { }
};
auto Recursive = [](auto Self, auto h, auto ... rest) {
return 1 + Self(Self, rest...);
};
auto Base = [](auto Self, auto h) {
return 1;
};
overload<decltype(Base), decltype(Recursive)> O(Base, Recursive);
int num_params = O(O, 5, 3, "abc", 3.14, 'a');
Please see attached tests for more examples.
Some implementation notes:
- Add a new Declarator context => LambdaExprParameterContext to
clang::Declarator to allow the use of 'auto' in declaring generic
lambda parameters
- Augment AutoType's constructor (similar to how variadic
template-type-parameters ala TemplateTypeParmDecl are implemented) to
accept an IsParameterPack to encode a generic lambda parameter pack.
- Add various helpers to CXXRecordDecl to facilitate identifying
and querying a closure class
- LambdaScopeInfo (which maintains the current lambda's Sema state)
was augmented to house the current depth of the template being
parsed (id est the Parser calls Sema::RecordParsingTemplateParameterDepth)
so that Sema::ActOnLambdaAutoParameter may use it to create the
appropriate list of corresponding TemplateTypeParmDecl for each
auto parameter identified within the generic lambda (also stored
within the current LambdaScopeInfo). Additionally,
a TemplateParameterList data-member was added to hold the invented
TemplateParameterList AST node which will be much more useful
once we teach TreeTransform how to transform generic lambdas.
- SemaLambda.h was added to hold some common lambda utility
functions (this file is likely to grow ...)
- Teach Sema::ActOnStartOfFunctionDef to check whether it
is being called to instantiate a generic lambda's call
operator, and if so, push an appropriately prepared
LambdaScopeInfo object on the stack.
- Teach Sema::ActOnStartOfLambdaDefinition to set the
return type of a lambda without a trailing return type
to 'auto' in C++1y mode, and teach the return type
deduction machinery in SemaStmt.cpp to process either
C++11 and C++14 lambda's correctly depending on the flag.
- various tests were added - but much more will be needed.
A greatful thanks to all reviewers including Eli Friedman,
James Dennett and the ever illuminating Richard Smith. And
yet I am certain that I have allowed unidentified bugs to creep in;
bugs, that I will do my best to slay, once identified!
Thanks!
llvm-svn: 188977
Add support for half (a.k.a. __fp16) in builtin descriptions.
The second argument to BUILTIN() now accepts 'h' to represent half.
Patch by Daniel Sanders
llvm-svn: 188464
We were exposing the extra alignment given to large arrays. The new behavior
matches gcc, which is a good thing since this is a gcc extension.
Thanks to Joerg Sonnenberger for noticing it.
While at it, centralize the method description in the .h file.
llvm-svn: 187999
Before this patch we would align
long long int big[1024];
to 4 bytes on 32 bit systems. The problem is that we were only looking
at the element type when getLargeArrayMinWidth returned non zero.
llvm-svn: 187897
via a macro, try using declaration's starting location.
This is improvement over not having a valid location and
dropping comment altogether. // rdar://14348912
llvm-svn: 187085
Hans Wennborg