| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
msvc.
llvm-svn: 260347
|
| |
|
|
|
|
| |
Suggested by Paul Robinson.
llvm-svn: 260346
|
| |
|
|
|
|
| |
I guess it would be working since Rafael's r187619.
llvm-svn: 260344
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: This isn't a FileCheck directive; it does nothing.
Reviewers: jroelofs
Subscribers: cfe-commits, majnemer
Differential Revision: http://reviews.llvm.org/D17051
llvm-svn: 260334
|
| |
|
|
|
|
| |
of digit separators.
llvm-svn: 260307
|
| |
|
|
| |
llvm-svn: 260276
|
| |
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D16947
llvm-svn: 260270
|
| |
|
|
| |
llvm-svn: 260266
|
| |
|
|
| |
llvm-svn: 260255
|
| |
|
|
|
|
|
|
|
|
| |
instantiation"
This reverts commit r260194.
It caused PR26549. There's probably a better way to do this also.
llvm-svn: 260241
|
| |
|
|
| |
llvm-svn: 260220
|
| |
|
|
| |
llvm-svn: 260213
|
| |
|
|
|
|
|
| |
Clang did not expanded macros in the very first token of the pragmas
during preprocessed output
llvm-svn: 260211
|
| |
|
|
|
|
| |
Fixes PR26490
llvm-svn: 260194
|
| |
|
|
| |
llvm-svn: 260161
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When handling 'if' statements, we crash if the condition and the consequent
branch are spanned by a single macro expansion.
The crash occurs because of a sanity 'reset' in popRegions(): if an expansion
exactly spans an entire region, we set MostRecentLocation to the start of the
expansion (its 'include location'). This ensures we don't handleFileExit()
ourselves out of the expansion before we're done processing all of the regions
within it. This is tested in test/CoverageMapping/macro-expressions.c.
This causes a problem when an expansion spans both the condition and the
consequent branch of an 'if' statement. MostRecentLocation is updated to the
start of the 'if' statement in popRegions(), so the file for the expansion
isn't exited by the time we're done handling the statement. We then crash with
'fatal: File exit not handled before popRegions'.
The fix for this is to detect these kinds of expansions, and conservatively
update MostRecentLocation to the end of expansion region containing the
conditional. I've added tests to make sure we don't have the same problem with
other kinds of statements.
rdar://problem/23630316
Differential Revision: http://reviews.llvm.org/D16934
llvm-svn: 260129
|
| |
|
|
| |
llvm-svn: 260126
|
| |
|
|
|
|
|
|
| |
specialized code generation for different devices.
This was reverted by r260036, but was not the cause of the problem in the buildbot.
llvm-svn: 260106
|
| |
|
|
|
|
|
|
|
|
| |
call x86_thiscallcc void @_ZN2SSC1ERi(
It matched to:
<call> x86_this<callcc void @_ZN2SSC1ERi(>
llvm-svn: 260093
|
| |
|
|
| |
llvm-svn: 260092
|
| |
|
|
| |
llvm-svn: 260091
|
| |
|
|
|
|
|
| |
OpenMP 4.5 introduces privatization of non-static data members of current class in non-static member functions.
To correctly handle such kind of privatization a new (pseudo)declaration VarDecl-based node is added. It allows to reuse an existing code for capturing variables in Lambdas/Block/Captured blocks of code for correct privatization and codegen.
llvm-svn: 260077
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
diagnosing when 'concept' is specified on a function or template
specialization.
Since a concept can only be applied to a function or variable template,
the concept bit is stored in TemplateDecl as a PointerIntPair.
Reviewers: rsmith, faisalv, aaron.ballman, hubert.reinterpretcast
Differential Revision: http://reviews.llvm.org/D13357
llvm-svn: 260074
|
| |
|
|
|
|
|
|
|
|
|
| |
LazyCompoundVal.
Instead, return UnknownValue if either operand is a nonloc::LazyCompoundVal. This is a
spot fix for PR 24951.
rdar://problem/23682244
llvm-svn: 260066
|
| |
|
|
|
|
|
|
| |
A dllimport'd vtable always points one past the RTTI data, this means
that the initializer will never end up referencing the data. Our
emission is a harmless waste.
llvm-svn: 260062
|
| |
|
|
| |
llvm-svn: 260058
|
| |
|
|
|
|
|
| |
This test hasn't been running after it was added until r259976 made
"REQUIRES: nozlib" work, and now that the test runs it fails.
llvm-svn: 260056
|
| |
|
|
|
|
|
|
|
| |
Now that the libcpp implementations of these methods has a branch that doesn't call
memmove(), the analyzer needs to invalidate the destination for these methods explicitly.
rdar://problem/23575656
llvm-svn: 260043
|
| |
|
|
|
|
|
|
| |
code generation for different devices."
This reverts commit r259985, as it still fails one buildbot.
llvm-svn: 260036
|
| |
|
|
| |
llvm-svn: 260022
|
| |
|
|
| |
llvm-svn: 260021
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adjust the driver to invoke the linker more similar to gcc. -dynamic-linker is
only passed if -static and -shared are not part of the compiler (driver)
invocation. Replicate the passing of -export-rdynamic as per the GCC link spec:
%{!static: %{rdynamic:-export-dynamic} %{!shared:-dynamic-linker ...}}
This behaviour is consistent across all the targets that are supported, so no
need to conditionalise it on the target.
Resolves PR24245.
llvm-svn: 260019
|
| |
|
|
|
|
|
|
|
|
|
| |
The ivar ref would be transformed by the Typo Correction TreeTransform, but not
be owned, resulting in the source location being invalid. This would eventually
lead to an assertion in findCapturingExpr. Prevent this assertion from
triggering.
Resolves PR25113.
llvm-svn: 260017
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We would previously assert in findCapturingExpr when performing a typo
correction resulting in an assignment of an ObjC property with a strong lifetype
specifier due to the expression not being rooted in the file (invalid SLoc)
during the retain cycle check on the typo-corrected expression. Handle the
expression type appropriately during the TreeTransform to ensure that we have a
source location associated with the expression.
Fixes PR26486.
llvm-svn: 260016
|
| |
|
|
|
|
|
| |
Add support for exposing the adjustment thunk for virtual methods as
appropriate.
llvm-svn: 260011
|
| |
|
|
|
|
|
|
|
| |
in dealloc.
It is common for the ivars for read-only assign properties to always be stored retained,
so don't warn for a release in dealloc for the ivar backing these properties.
llvm-svn: 259998
|
| |
|
|
|
|
|
|
| |
generation for different devices.
This was reverted due to a failure in a buildbot, but it turned out the failure was unrelated.
llvm-svn: 259985
|
| |
|
|
|
|
|
|
| |
generation for different devices.
It triggered some problem in the configuration related with zlib and exposed in the driver.
llvm-svn: 259984
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
devices.
Summary:
Different devices may in some cases require different code generation schemes in order to implement OpenMP. This is required not only for performance reasons, but also because it may not be possible to have the current (default) implementation working for these devices. E.g. GPU's cannot implement the same scheme a target such as powerpc or x86b would use, in the sense that it does not have the ability to fork threads, instead all the threads are always executing and need to be managed by the implementation.
This patch proposes a reorganization of the code in the OpenMP code generation to pave the way to have specialized implementation of OpenMP support. More than a "real" patch this is more a request for comments in order to understand if what is proposed is acceptable or if there are better/easier ways to do it.
In this patch part of the common OpenMP codegen infrastructure is moved to a new file under a new namespace (CGOpenMPCommon) so it can be shared between the default implementation and the specialized one. When CGOpenMPRuntime is created, an attempt to select a specialized implementation is done.
In the patch a specialization for nvptx targets is done which currently checks if the target is an OpenMP device and trap if it is not.
Let me know comments suggestions you may have.
Reviewers: hfinkel, carlo.bertolli, arpith-jacob, kkwli0, ABataev
Subscribers: Hahnfeld, cfe-commits, fraggamuffin, caomhin, jholewinski
Differential Revision: http://reviews.llvm.org/D16784
llvm-svn: 259977
|
| |
|
|
|
|
| |
of -fembed-all-files mode.
llvm-svn: 259976
|
| |
|
|
|
|
|
|
|
|
| |
It is possible for enums to be created as part of their own
declcontext. We need to cache a placeholder to avoid the type being
created twice before hitting the cache.
<rdar://problem/24493203>
llvm-svn: 259975
|
| |
|
|
|
|
|
|
| |
Temporarily relax check in test to avoid
breakage for format change in LLVM side. Once that is
done, the test case will be retightened.
llvm-svn: 259955
|
| |
|
|
|
|
|
|
| |
Sometimes, char arrays are used as bit storage, with no difference made between
signed and unsigned char. Thus, it is reasonable to use 0 to 255 instead of
-128 to 127 and not trigger this warning.
llvm-svn: 259947
|
| |
|
|
|
|
| |
rdar://24531556
llvm-svn: 259932
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_[1248] macros on SystemZ.
This fixes a miscompile of GCC C++11 standard library headers
due to use of those macros in an ABI-changing manner.
See e.g. /usr/include/c++/4.8.5/ext/concurrence.h:
// Compile time constant that indicates prefered locking policy in
// the current configuration.
static const _Lock_policy __default_lock_policy =
#ifdef __GTHREADS
#if (defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2) \
&& defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4))
_S_atomic;
#else
_S_mutex;
#endif
#else
_S_single;
#endif
A different choice of __default_lock_policy causes different
sizes of several of the C++11 data structures, which are then
incompatible when inlined in clang-compiled code with what the
(GCC-compiled) external library expects.
This in turn leads to various crashes when using std::thread
in code compiled with clang, as see e.g. via the ThreadPool
unit tests. See PR 26473 for an example.
llvm-svn: 259931
|
| |
|
|
|
|
|
|
| |
This change reverts r257462 for PS4 triple.
Differential Revision: http://reviews.llvm.org/D16788
llvm-svn: 259916
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the context where we break one tok::greatergreater into two
tok::greater in order to correctly update the cached tokens; update the
CachedTokens with two tok::greater only if ParseGreaterThanInTemplateList
clients asks to consume the last token. Otherwise we only need to add
one because the second is already added later on, as a not yet cached token.
Differential Revision: http://reviews.llvm.org/D16906
rdar://problem/24488367
llvm-svn: 259910
|
| |
|
|
|
|
|
|
|
|
| |
name lookup information have changed since deserialization. For a C++ modules
build, we do not need to re-emit the identifier into the serialized identifier
table if only the name lookup information has changed (and in all cases, we
don't need to re-emit the macro information if only the name lookup information
has changed).
llvm-svn: 259901
|
| |
|
|
|
|
|
| |
If the class or method name case-insensitively contains the term "debug",
suppress warnings about string constants flowing to user-facing UI APIs.
llvm-svn: 259875
|
| |
|
|
|
|
|
|
|
|
|
| |
Because the Decl is explicitly passed as nullptr further up the call chain, it
is possible to invoke isa on a nullptr, which will assert. Guard against the
nullptr.
Take the opportunity to reuse the helper method rather than re-implementing this
logic.
llvm-svn: 259874
|