C++ programs compiled for profiling (using `-pg`) should be linked with
`-lc++_p` (or `-lstdc++_p`, depending on the `-stdlib=` setting), not
with the regular C++ libraries.

Add a `FreeBSD::AddCXXStdlibLibArgs()` override to handle this, and add
a test case for it.  While here, extend the test case for the proper
passing of -lm and -lm_p.

Reviewers: compnerd, davide, dws, emaste
Reviewed By: compnerd
Differential Revision: http://reviews.llvm.org/D16264


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

Found by lsan.

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

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

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

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

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

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

Summary:
Unlike other outlined regions in OpenMP, offloading entry points have to have be visible (external linkage) for the device side. Using dots in the names of the entries can be therefore problematic for some toolchains, e.g. NVPTX.

Also the patch drops the column information in the unique name of the entry points. The parsing of directives ignore unknown tokens, preventing several target  regions to be implemented in the same line. Therefore, the line information is sufficient for the name to be unique. Also, the preprocessor printer does not preserve the column information, causing offloading-entry detection issues if the host uses an integrated preprocessor and the target doesn't (or vice versa).

Reviewers: hfinkel, arpith-jacob, carlo.bertolli, kkwli0, ABataev

Subscribers: cfe-commits, fraggamuffin, caomhin

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

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

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

Storing std::strings in attributes simply doesn't work, we never call
the destructor. Use an array of StringRefs instead of std::strings and
copy the data into memory taken from the ASTContext.

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

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

Also remove the now unused isPodLike specialization. DenseMap only uses
it for copies.

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

Reduce the number of implicit StringRef->std::string conversions by threading StringRef through more APIs.

No functionality change intended.

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

Found by asan.

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

New implementation is easier to read and extend.

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

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

Many thanks to Yunzhong Gao for tracking this down!

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

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

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


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

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


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

This is a follow-up to PR26085. That was fixed in r257710 but the testcase
there was incomplete. There is a related issue where the overload resolution
for Objective-C incorrectly picks a method that is not valid without a
bridge cast. The call to Sema::CheckSingleAssignmentConstraints that was
added to SemaOverload.cpp's IsStandardConversion() function does not catch
that case and reports that the method is Compatible even when it is not.

The root cause here is that various Objective-C-related functions in Sema
do not consistently return a value to indicate whether there was an error.
This was fine in the past because they would report diagnostics when needed,
but r257710 changed them to suppress reporting diagnostics when checking
during overload resolution.

This patch adds a new ACR_error result to the ARCConversionResult enum and
updates Sema::CheckObjCARCConversion to return that value when there is an
error. Most of the calls to that function do not check the return value,
so adding this new result does not affect them. The one exception is in
SemaCast.cpp where it specifically checks for ACR_unbridged, so that is
also OK. The call in Sema::CheckSingleAssignmentConstraints can then check
for an ACR_okay result and identify assignments as Incompatible. To
preserve the existing behavior, it only changes the return value to
Incompatible when the new Diagnose argument (from r257710) is false.

Similarly, the CheckObjCBridgeRelatedConversions and
ConversionToObjCStringLiteralCheck need to identify when an assignment is
Incompatible. Those functions already return appropriate values but they
need some fixes related to the new Diagnose argument.

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

[RecursiveASTVisitor] Introduce dataTraverseStmtPre()/dataTraverseStmtPost() to allow clients to do before/after actions during data recursive visitation.

This should fix the asan bot that hits stack overflow in a couple of test/Index tests.

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

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

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

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

When a null constant is used in a macro, walk through the macro stack to
determine where the null constant is written and where the context is located.
Only warn if both locations are within the same macro expansion.  This helps
function-like macros which involve pointers be treated as if they were
functions.


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

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

[libclang] Separate the underlying indexing functionality of libclang and introduce it into the clangIndex library.

It is a general goodness for libclang itself to mostly be a wrapper of functionality provided by the libraries.

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

Differential revision: http://reviews.llvm.org/D17218


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

Recent refactoring meant it only got passed down when explicitly specified,
which breaks header search on Darwin.

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

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

Summary:
This commit re-lands r259862. The underlying cause of the build breakage was an incorrectly written capabilities test. In tools/Driver/CMakeLists.txt I was attempting to check if a linker flag worked, the test was passing it to the compiler, not the linker. CMake doesn't have a linker test, so we have a hand-rolled one.

Original Patch Review: http://reviews.llvm.org/D16896

Original Summary:
With this change generating clang order files using dtrace uses the following workflow:

cmake <whatever options you want>

ninja generate-order-file

ninja clang

This patch works by setting a default path to the order file (which can be overridden by the user). If the order file doesn't exist during configuration CMake will create an empty one.

CMake then ties up the dependencies between the clang link job and the order file, and generate-order-file overwrites CLANG_ORDER_FILE with the new order file.

Reviewers: bogner

Subscribers: cfe-commits

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

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

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

For *_MANT_DIG, *_MAX_EXP and *_MIN_EXP, the C Standard does not list
the least requirements directly. This patch adjusts the test values with
refined ones.

Patch by Jorge Teixeira!


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

No functional change is intended.

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

This was originally a hacky if(APPLE) block. Now that we have an option for enabling LTO, it is better to properly gate this.

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

This is an artefact of split-mode CUDA compilation that we need to
mimic. HD functions are sometimes allowed to call H or D functions. Due
to split compilation mode device-side compilation will not see host-only
function and thus they will not be considered at all. For clang both H
and D variants will become function overloads visible to
compiler. Normally target attribute is considered only if C++ rules can
not determine which function is better. However in this case we need to
ignore functions that would not be present during current compilation
phase before we apply normal overload resolution rules.

Changes:
* introduced another level of call preference to better describe
  possible call combinations.
* removed WrongSide functions from consideration if the set contains
  SameSide function.
* disabled H->D, D->H and G->H calls. These combinations are
  not allowed by CUDA and we were reluctantly allowing them to work
  around device-side calls to math functions in std namespace.
  We no longer need it after r258880.

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

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

The DataLayout can calculate alignment of vectors based on the alignment
of the element type and the number of elements. In fact, it is the product
of these two values. The problem is that for vectors of N x i1, this will
return the alignment of N bytes, since the alignment of i1 is 8 bits. The
vector types of vNi1 should be aligned to N bits instead. Provide explicit
alignment for HVX vectors to avoid such complications.



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

Fix a crash while parsing this code:

  struct X  {
    friend constexpr int foo(X*) { return 12; }
    static constexpr int j = foo(static_cast<X*>(nullptr));
  };

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

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

The library functions defined in the C99 standard headers
are not available (OpenCL v1.2 s6.9.f). 

This change stops treating OpenCL builtin functions as standard C lib
functions to eliminate warning messages about printf format string.

Patch by Liu Yaxun (Sam)!

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



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

With this option one can optionally override the architecture dependent
default library to use if no -stdlib= is provided on compiler invocation.

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

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