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
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
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
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
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
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
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
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
This will be needed for the next commit that allows to switch the default
C++ library which would otherwise make these tests fail.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260661 91177308-0d34-0410-b5e6-96231b3b80d8
Look through PseudoObjectExpr and OpaqueValueExprs when scanning for
release-like operations. This commit also adds additional tests in anticipation
of re-writing this as a path-sensitive checker.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260608 91177308-0d34-0410-b5e6-96231b3b80d8
You can override the value of these during CMake, and we often use sentinels
with more than one digit (not to mention our actual Clang being 700.whatever).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260596 91177308-0d34-0410-b5e6-96231b3b80d8
This commit changes the root from "Simple C/C++ TBAA" to "Simple C++ TBAA" for
C++.
The problem is that the type name in the TBAA nodes is generated differently
for C vs C++. If we link an IR file for C with an IR file for C++, since they
have the same root and the type names are different, accesses to the two type
nodes will be considered no-alias, even though the two type nodes are from
the same type in a header file.
The fix is to use different roots for C and C++. Types from C will be treated
conservatively in respect to types from C++.
Follow-up commits will change the C root to "Simple C TBAA" plus some mangling
change for C types to make it a little more aggresive.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260567 91177308-0d34-0410-b5e6-96231b3b80d8
If we didn't tell ReadOptionsBlock to allow failures then we can't
assume that the stream is not in the middle of a block if it returns
out-of-date. This was causing a crash when we tried to continue reading.
Also, it's just generally a good idea to early-exit if we're doing
implicit module builds, since we will want to immediately rebuild this
module anyway and there's no reason to waste time continuing after
failure.
rdar://problem/24114938
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260563 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r260449.
We would supress our emission of vftable definitions if we thought
another translation unit would provide the definition because we saw an
explicit instantiation declaration. This is not the case with
dllimport, we want to synthesize a definition of the vftable regardless.
This fixes PR26569.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260548 91177308-0d34-0410-b5e6-96231b3b80d8
Update the Preprocessor's VisibleModuleSet when typo-correction creates
an implicit module import so that we won't accidentally write an invalid
SourceLocation into the preamble AST. This would later lead to infinite
recursion when loading the preamble AST because we use the value in
ImportLocs to prevent visiting a module twice.
rdar://problem/24440990
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260543 91177308-0d34-0410-b5e6-96231b3b80d8
This required fixing a few check lines which had omitted trailing
characters, and were passing incorrectly (e.g., asserting that
__UINT64_C_SUFFIX__ is "UL" instead of the "ULL" that it actually is set
to). All were obviously broken tests, not broken code.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260542 91177308-0d34-0410-b5e6-96231b3b80d8
This allows ARMv8.2-A to be targeted either by using "armv8.2a" in the
triple, or by using -march=armv8.2-a (or the alias -march=armv8.2a).
The FP16 extension can be enabled with the "+fp16" suffix to the -march
or -mcpu option. This is consistent with the AArch64 option, rather than
the usual ARM option of -mfpu. We have agreed with the team which will
be upstreaming this to GCC that we want to use this new option format
for new architecture extensions for both ARM and AArch64.
Most of the work for this was done by the TargetParser patch in llvm.
Differential Revision: http://reviews.llvm.org/D15040
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260533 91177308-0d34-0410-b5e6-96231b3b80d8
Argyrios Kyrtzidis
NAKAMURA Takumi
Steven Watanabe
Sunil Srivastava
Bob Wilson
Matt Arsenault
Alexey Samsonov
Richard Trieu
Eugene Zelenko
Tim Northover
Chris Bieneman
Artem Belevich
Hubert Tong
David Majnemer
Krzysztof Parzyszek
Olivier Goffart
Anastasia Stulova
Jonas Hahnfeld
Eric Christopher
Richard Smith
Hans Wennborg
Mike Aizatsky
Joerg Sonnenberger
Devin Coughlin
Carlo Bertolli
Manman Ren
Ben Langmuir
Chad Rosier
James Y Knight
Oliver Stannard
Rafael Espindola