git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253069 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253066 91177308-0d34-0410-b5e6-96231b3b80d8

When linking against text-based dynamic library SDKs the library name of a
framework has now more than one possible filename extensions. This fix tests for
both possible extensions (none, and .tbd).

This fixes rdar://problem/20609975

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253060 91177308-0d34-0410-b5e6-96231b3b80d8

It has been reported that this test currently fails on some Power buildbots due to them adding a "signext" function attribute.

As that's not what we're checking here, slacken off the test a bit.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253055 91177308-0d34-0410-b5e6-96231b3b80d8

While functions types are complete, they cannot be constructed.

This fixes PR25513.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253013 91177308-0d34-0410-b5e6-96231b3b80d8

actually hidden before we check its linkage. This avoids computing the linkage
"too early" for an anonymous struct with a typedef name for linkage.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253012 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253011 91177308-0d34-0410-b5e6-96231b3b80d8

the linkage of the enumeration. For enumerators of unnamed enumerations, extend
the -Wmodules-ambiguous-internal-linkage extension to allow selecting an
arbitrary enumerator (but only if they all have the same value, otherwise it's
ambiguous).


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253010 91177308-0d34-0410-b5e6-96231b3b80d8

The ``disable_tail_calls`` attribute instructs the backend to not
perform tail call optimization inside the marked function.

For example, 

int callee(int);

int foo(int a) __attribute__((disable_tail_calls)) {
  return callee(a); // This call is not tail-call optimized.
}

Note that this attribute is different from 'not_tail_called', which
prevents tail-call optimization to the marked function.

rdar://problem/8973573

Differential Revision: http://reviews.llvm.org/D12547


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252986 91177308-0d34-0410-b5e6-96231b3b80d8

I will remove REQUIRES later.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252972 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252971 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252967 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252961 91177308-0d34-0410-b5e6-96231b3b80d8

declarations in redeclaration lookup. A declaration is now visible to
lookup if:

 * It is visible (not in a module, or in an imported module), or
 * We're doing redeclaration lookup and it's externally-visible, or
 * We're doing typo correction and looking for unimported decls.

We now support multiple modules having different internal-linkage or no-linkage
definitions of the same name for all entities, not just for functions,
variables, and some typedefs. As previously, if multiple such entities are
visible, any attempt to use them will result in an ambiguity error.

This patch fixes the linkage calculation for a number of entities where we
previously didn't need to get it right (using-declarations, namespace aliases,
and so on).  It also classifies enumerators as always having no linkage, which
is a slight deviation from the C++ standard's definition, but not an observable
change outside modules (this change is being discussed on the -core reflector
currently).

This also removes the prior special case for tag lookup, which made some cases
of this work, but also led to bizarre, bogus "must use 'struct' to refer to type
'Foo' in this scope" diagnostics in C++.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252960 91177308-0d34-0410-b5e6-96231b3b80d8

DR407, the C++ standard doesn't really say how this should work. Here's what we
do (which is consistent with DR407 as far as I can tell):

 * When performing name lookup for an elaborated-type-specifier, a tag
   declaration hides a typedef declaration that names the same type.
 * When performing any other kind of lookup, a typedef declaration hides
   a tag declaration that names the same type.

In any other case where lookup finds both a typedef and a tag (that is, when
they name different types), the lookup will be ambiguous. If lookup finds a
tag and a typedef that name the same type, and finds anything else, the lookup
will always be ambiguous (even if the other entity would hide the tag, it does
not also hide the typedef).


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252959 91177308-0d34-0410-b5e6-96231b3b80d8

This failed to solve the problem it was aimed at, and introduced just as many
issues as it resolved. Realistically, we need to deal with the possibility that
multiple modules might define different internal linkage symbols with the same
name, and this isn't a problem unless two such symbols are simultaneously
visible.

The case where two modules define equivalent internal linkage symbols is
handled by r252063: if lookup finds multiple sufficiently-similar entities from
different modules, we just pick one of them as an extension (but we keep them
separate).


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252957 91177308-0d34-0410-b5e6-96231b3b80d8

From a patch by Nicholas Allegra!


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252955 91177308-0d34-0410-b5e6-96231b3b80d8

In r244063, I had caused these builtins to call the same-named library
functions, __atomic_*_fetch_SIZE. However, this was incorrect: while
those functions are in fact supported by GCC's libatomic, they're not
documented by the spec (and gcc doesn't ever call them).

Instead, you're /supposed/ to call the __atomic_fetch_* builtins and
then redo the operation inline to return the final value.

Differential Revision: http://reviews.llvm.org/D14385

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252920 91177308-0d34-0410-b5e6-96231b3b80d8

This option is used to cancel -mms-bitfields on the command line.

rdar://problem/15898553


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252912 91177308-0d34-0410-b5e6-96231b3b80d8

The C++ spec (3.6.1.3) says "The function `main` shall not be used within a program". This implies that it cannot recurse, so add the norecurse attribute to help the midend out a bit.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252902 91177308-0d34-0410-b5e6-96231b3b80d8

Last time, this caused two Windows buildbots and a single ARM buildbot to fail.
I XFAIL'd the failing test on win32,win64 machines in order to see if the ARM
buildbot complains again.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252901 91177308-0d34-0410-b5e6-96231b3b80d8

FunctionAttrs has just been taught how to infer 'norecurse'. Update clang tests for LLVM r252871.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252872 91177308-0d34-0410-b5e6-96231b3b80d8

This function permits the mangling of a C++ 'structor.  Depending on the ABI and
the declaration, the declaration may contain more than one associated symbol for
a given declaration.  This allows the consumer to retrieve all of the associated
symbols for the declaration the cursor points to.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252853 91177308-0d34-0410-b5e6-96231b3b80d8

target features that the caller function doesn't provide. This matches
the existing backend failure to inline functions that don't have
matching target features - and diagnoses earlier in the case of
always_inline.

Fix up a few test cases that were, in fact, invalid if you tried
to generate code from the backend with the specified target features
and add a couple of tests to illustrate what's going on.

This should fix PR25246.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252834 91177308-0d34-0410-b5e6-96231b3b80d8

Summary: Diagnose when a function concept declaration has parameter(s)

Reviewers: rsmith, faisalv, aaron.ballman, hubert.reinterpretcast

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D14352

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252827 91177308-0d34-0410-b5e6-96231b3b80d8

This is about how we handle static member of a template. Before this commit,
we use internal linkage for the IR thread-local variable, which is inefficient.
With this commit, we will start to follow Itanium C++ ABI.

rdar://problem/23415206

Reviewed by John McCall.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252814 91177308-0d34-0410-b5e6-96231b3b80d8

Expected diagnostics have been expanded to vary by C++ dialect.
RUN line has also been expanded to: default, C++98/03 and C++11.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252785 91177308-0d34-0410-b5e6-96231b3b80d8

We used to emit the store prior to branch in the entry block. To make it more
efficient, this commit moves it to the init block. We still mark as initialized
before initializing anything else.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252777 91177308-0d34-0410-b5e6-96231b3b80d8

    
Differential Revision: http://reviews.llvm.org/D14243


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252721 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
For clarity and ease of maintenance, I suggest porting this test
to use the same tooling as the rest of the tests.

Reviewers: joerg, rengolin, dougk, yaron.keren

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D14548

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252720 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Add 'pause' builtin that's already in llvm and use it instead of inline assembly to implement _mm_pause.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252712 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Use __builtin_ia32_paddq and __builtin_ia32_psubq to implement a couple intrinsics that were supposed to operate on MMX registers. Otherwise we end up operating on GPRs. Throw in a test for _mm_mul_su32 while I was there.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252711 91177308-0d34-0410-b5e6-96231b3b80d8

rdar://problem/19836465


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252693 91177308-0d34-0410-b5e6-96231b3b80d8

https://gcc.gnu.org/onlinedocs/gcc/Typeof.html

Differences from the GCC extension:
 * __auto_type is also permitted in C++ (but only in places where
   it could appear in C), allowing its use in headers that might
   be shared across C and C++, or used from C++98
 * __auto_type can be combined with a declarator, as with C++ auto
   (for instance, "__auto_type *p")
 * multiple variables can be declared in a single __auto_type
   declaration, with the C++ semantics (the deduced type must be
   the same in each case)

This patch also adds a missing restriction on applying typeof to
a bit-field, which GCC has historically rejected in C (due to
lack of clarity as to whether the operand should be promoted).
The same restriction also applies to __auto_type in C (in both
GCC and Clang).

This also fixes PR25449.

Patch by Nicholas Allegra!


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252690 91177308-0d34-0410-b5e6-96231b3b80d8

std::initializer_list<T> type. Instead, the list must contain a single element
and the type is deduced from that.

In Clang 3.7, we warned by default on all the cases that would change meaning
due to this change. In Clang 3.8, we will support only the new rules -- per
the request in N3922, this change is applied as a Defect Report against earlier
versions of the C++ standard.

This change is not entirely trivial, because for lambda init-captures we
previously did not track the difference between direct-list-initialization and
copy-list-initialization. The difference was not previously observable, because
the two forms of initialization always did the same thing (the elements of the
initializer list were always copy-initialized regardless of the initialization
style used for the init-capture).


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252688 91177308-0d34-0410-b5e6-96231b3b80d8

This is now allowed and has the behavior of removing the mapping.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252679 91177308-0d34-0410-b5e6-96231b3b80d8

This was an accidental regression from the MRC __weak patch.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252668 91177308-0d34-0410-b5e6-96231b3b80d8

This comes up when a derived class destructor is equivalent to a base
class destructor defined in the same TU, and we try to alias them.

A COFF weak alias cannot satisfy a normal undefined symbol reference
from another TU. The other TU must also mark the referenced symbol as
weak, and we can't rely on that.

Clang already has a special case here for dllexport, but we failed to
realize that the problem also applies to other non-discardable symbols
such as those from explicit template instantiations.

Fixes PR25477.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252659 91177308-0d34-0410-b5e6-96231b3b80d8

The attrubite is applicable to functions and variables and changes
the linkage of the subject to internal.

This is the same functionality as C-style "static", but applicable to
class methods; and the same as anonymouns namespaces, but can apply
to individual methods of a class.

Following the proposal in
http://lists.llvm.org/pipermail/cfe-dev/2015-October/045580.html

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252648 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252646 91177308-0d34-0410-b5e6-96231b3b80d8