intrin.h had forward declarations for these and lzcntintrin.h had implementations that were only available with -mlzcnt or a -march that supported the lzcnt feature.
For MS compatibility we should always have these builtins available regardless of X86 being the target or the CPU support the lzcnt instruction. The backends should be able to gracefully fallback to something support even if its just shifts and bit ops.
Unfortunately, gcc also implements 2 of the 3 function names here on X86 when lzcnt feature is enabled.
This patch adds builtins for these for MSVC compatibility and drops the forward declarations from intrin.h. To keep the gcc compatibility the two intrinsics that collided have been turned into macros that use the X86 specific builtins with the lzcnt feature check. These macros are only defined when _MSC_VER is not defined. Without them being macros we can get a redefinition error because -ms-extensions doesn't seem to set _MSC_VER but does make the MS builtins available.
Should fix PR40014
Differential Revision: https://reviews.llvm.org/D55677
llvm-svn: 349098
Address spaces are cast into generic before invoking the constructor.
Added support for a trailing Qualifiers object in FunctionProtoType.
Note: This recommits the previously reverted patch,
but now it is commited together with a fix for lldb.
Differential Revision: https://reviews.llvm.org/D54862
llvm-svn: 349019
Summary:
This change adds a new AST matcher for block expressions.
Test Notes:
Ran the clang unit tests.
Reviewers: aaron.ballman
Reviewed By: aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D55546
llvm-svn: 349004
Summary:
Currently the Clang AST doesn't store information about how the callee of a CallExpr was found. Specifically if it was found using ADL.
However, this information is invaluable to tooling. Consider a tool which renames usages of a function. If the originally CallExpr was formed using ADL, then the tooling may need to additionally qualify the replacement.
Without information about how the callee was found, the tooling is left scratching it's head. Additionally, we want to be able to match ADL calls as quickly as possible, which means avoiding computing the answer on the fly.
This patch changes `CallExpr` to store whether it's callee was found using ADL. It does not change the size of any AST nodes.
Reviewers: fowles, rsmith, klimek, shafik
Reviewed By: rsmith
Subscribers: aaron.ballman, riccibruno, calabrese, titus, cfe-commits
Differential Revision: https://reviews.llvm.org/D55534
llvm-svn: 348977
Clang's CallGraph analysis doesn't use the RecursiveASTVisitor's setting
togo into template instantiations. The result is that anything wanting
to do call graph analysis ends up missing any template function calls.
Change-Id: Ib4af44ed59f15d43f37af91622a203146a3c3189
llvm-svn: 348942
Summary:
`memchr` and `memcmp` operate upon the character units of the object
representation; that is, the `size_t` parameter expresses the number of
character units. The constant folding implementation is updated in this
patch to account for multibyte element types in the arrays passed to
`memchr`/`memcmp` and, in the case of `memcmp`, to account for the
possibility that the arrays may have differing element types (even when
they are byte-sized).
Actual inspection of the object representation is not implemented.
Comparisons are done only between elements with the same object size;
that is, `memchr` will fail when inspecting at least one character unit
of a multibyte element. The integer types are assumed to have two's
complement representation with 0 for `false`, 1 for `true`, and no
padding bits.
`memcmp` on multibyte elements will only be able to fold in cases where
enough elements are equal for the answer to be 0.
Various tests are added to guard against incorrect folding for cases
that miscompile on some system or other prior to this patch. At the same
time, the unsigned 32-bit `wchar_t` testing in
`test/SemaCXX/constexpr-string.cpp` is restored.
Reviewers: rsmith, aaron.ballman, hfinkel
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D55510
llvm-svn: 348938
Summary:
Added support for the -gline-directives-only option + fixed logic of the
debug info for CUDA devices. If optimization level is O0, then options
--[no-]cuda-noopt-device-debug do not affect the debug info level. If
the optimization level is >O0, debug info options are used +
--no-cuda-noopt-device-debug is used or no --cuda-noopt-device-debug is
used, the optimization level for the device code is kept and the
emission of the debug directives is used.
If the opt level is > O0, debug info is requested +
--cuda-noopt-device-debug option is used, the optimization is disabled
for the device code + required debug info is emitted.
Reviewers: tra, echristo
Subscribers: aprantl, guansong, JDevlieghere, cfe-commits
Differential Revision: https://reviews.llvm.org/D51554
llvm-svn: 348930
Address spaces are cast into generic before invoking the constructor.
Added support for a trailing Qualifiers object in FunctionProtoType.
Differential Revision: https://reviews.llvm.org/D54862
llvm-svn: 348927
The AST matcher documentation dumping script was being a bit over-zealous about stripping comment markers, which ended up causing comments in example code to stop being comments. Fix that by only stripping comments at the start of a line, rather than removing any forward slash (which also impacts prose text).
llvm-svn: 348891
Implement support for try-catch blocks in constexpr functions, as
proposed in http://wg21.link/P1002 and voted in San Diego for c++20.
The idea is that we can still never throw inside constexpr, so the catch
block is never entered. A try-catch block like this:
try { f(); } catch (...) { }
is then morally equivalent to just
{ f(); }
Same idea should apply for function/constructor try blocks.
rdar://problem/45530773
Differential Revision: https://reviews.llvm.org/D55097
llvm-svn: 348789
The addcarry and addcarryx builtins do the same thing. The only difference is that addcarryx previously required adx feature.
This commit removes the adx feature check from addcarryx and removes the addcarry builtin. This matches the builtins that gcc has. We don't guarantee compatibility in builtins, but we generally try to be consistent if its not a burden.
llvm-svn: 348738
It is faster to directly call the ObjC runtime for methods such as alloc/allocWithZone instead of sending a message to those functions.
This patch adds support for converting messages to alloc/allocWithZone to their equivalent runtime calls.
Tests included for the positive case of applying this transformation, negative tests that we ensure we only convert "alloc" to objc_alloc, not "alloc2", and also a driver test to ensure we enable this only for supported runtime versions.
Reviewed By: rjmccall
https://reviews.llvm.org/D55349
llvm-svn: 348687
Move enums from */*Diagnostic.h to Basic/Diagnostic*.h. Basic/AllDiagnostics.h
needs all the enums and moving the sources to Basic prevents a Basic->*->Basic
dependency loop. This also allows each Basic/Diagnostics*Kinds.td to have a
header at Basic/Diagnostic*.h (except for Common). The old headers are kept in place since other packages are still using them.
llvm-svn: 348685
Change in r337953 violated the contract for `CXTranslationUnit_KeepGoing`:
> Do not stop processing when fatal errors are encountered.
Use different approach to fix long processing times with multiple inclusion
cycles. Instead of stopping preprocessing for fatal errors, do this after
reaching the max allowed include depth and only for the files that were
processed already. It is likely but not guaranteed those files cause a cycle.
rdar://problem/46108547
Reviewers: erik.pilkington, arphaman
Reviewed By: erik.pilkington
Subscribers: jkorous, dexonsmith, ilya-biryukov, Dmitry.Kozhevnikov
Differential Revision: https://reviews.llvm.org/D55095
llvm-svn: 348641
Allow enabling and disabling tracking of ObjC/CF objects
separately from tracking of OS objects.
Differential Revision: https://reviews.llvm.org/D55400
llvm-svn: 348638
Summary:
We introduce a strict policy for C++ CTU. It can work across TUs only if
the C++ dialects are the same. We neither allow C vs C++ CTU. We do this
because the same constructs might be represented with different properties in
the corresponding AST nodes or even the nodes might be completely different (a
struct will be RecordDecl in C, but it will be a CXXRectordDecl in C++, thus it
may cause certain assertions during cast operations).
Reviewers: xazax.hun, a_sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Differential Revision: https://reviews.llvm.org/D55134
llvm-svn: 348610
Summary:
With a new switch we may be able to print to stderr if a new TU is being loaded
during CTU. This is very important for higher level scripts (like CodeChecker)
to be able to parse this output so they can create e.g. a zip file in case of
a Clang crash which contains all the related TU files.
Reviewers: xazax.hun, Szelethus, a_sidorin, george.karpenkov
Subscribers: whisperity, baloghadamsoftware, szepet, rnkovacs, a.sidorin, mikhail.ramalho, donat.nagy, dkrupp,
Differential Revision: https://reviews.llvm.org/D55135
llvm-svn: 348594
The attribute specifies that the call of the C++ method consumes a
reference to "this".
Differential Revision: https://reviews.llvm.org/D55155
llvm-svn: 348532
Friend function template defined in a class template becomes available if
the enclosing class template is instantiated. Until the function template
is used, it does not have a body, but still is considered a definition for
the purpose of redeclaration checks.
This change modifies redefinition check so that it can find the friend
function template definitions in instantiated classes.
Differential Revision: http://reviews.llvm.org/D21508
llvm-svn: 348473
This patch adds the noderef attribute in clang and checks for dereferences of
types that have this attribute. This attribute is currently used by sparse and
would like to be ported to clang.
Differential Revision: https://reviews.llvm.org/D49511
llvm-svn: 348442
Summary:
Start by moving some utilities to it. It will eventually house dumping
of individual nodes (after indentation etc has already been accounted
for).
Reviewers: aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D55189
llvm-svn: 348412
This adds a callback to PrintingPolicy to allow CGDebugInfo to remap
file paths according to -fdebug-prefix-map. Otherwise the debug info
(particularly function names for C++ lambdas) may contain paths that
should have been remapped in the debug info.
<rdar://problem/46128056>
Differential Revision: https://reviews.llvm.org/D55137
llvm-svn: 348397
The Entry pointer in IdentifierInfo was only null for IdentifierInfo
created from a PTH. Now that PTH support has been removed we can remove
some PTH specific code in IdentifierInfo::getLength and
IdentifierInfo::getNameStart.
Also make the constructor of IdentifierInfo private to make sure that
they are only created by IdentifierTable, and move it to the header so
that it can be inlined in IdentifierTable::get and IdentifierTable::getOwn.
Differential Revision: https://reviews.llvm.org/D54866
Reviewed By: erichkeane
llvm-svn: 348384
Added new diagnostic when templates are instantiated with
different address space from the one provided in its definition.
This also prevents deducing generic address space in pointer
type of templates to allow giving them concrete address space
during instantiation.
Differential Revision: https://reviews.llvm.org/D55127
llvm-svn: 348382
ArrayTypeTraitExpr is the only expression class which is polymorphic.
As far as I can tell this is completely pointless.
Differential Revision: https://reviews.llvm.org/D55221
Reviewed By: aaron.ballman
llvm-svn: 348276
When debugging a boost build with a modified
version of Clang, I discovered that the PTH implementation
stores TokenKind in 8 bits. However, we currently have 368
TokenKinds.
The result is that the value gets truncated and the wrong token
gets picked up when including PTH files. It seems that this will
go wrong every time someone uses a token that uses the 9th bit.
Upon asking on IRC, it was brought up that this was a highly
experimental features that was considered a failure. I discovered
via googling that BoostBuild (mostly Boost.Math) is the only user of
this
feature, using the CC1 flag directly. I believe that this can be
transferred over to normal PCH with minimal effort:
https://github.com/boostorg/build/issues/367
Based on advice on IRC and research showing that this is a nearly
completely unused feature, this patch removes it entirely.
Note: I considered leaving the build-flags in place and making them
emit an error/warning, however since I've basically identified and
warned the only user, it seemed better to just remove them.
Differential Revision: https://reviews.llvm.org/D54547
Change-Id: If32744275ef1f585357bd6c1c813d96973c4d8d9
llvm-svn: 348266
If an iterator is represented by a derived C++ class but its comparison operator
is for its base the iterator checkers cannot recognize the iterators compared.
This results in false positives in very straightforward cases (range error when
dereferencing an iterator after disclosing that it is equal to the past-the-end
iterator).
To overcome this problem we always use the region of the topmost base class for
iterators stored in a region. A new method called getMostDerivedObjectRegion()
was added to the MemRegion class to get this region.
Differential Revision: https://reviews.llvm.org/D54466
llvm-svn: 348244
Summary:
In our codebase, `static_assert(std::some_type_trait<Ts...>::value, "msg")`
(where `some_type_trait` is an std type_trait and `Ts...` is the
appropriate template parameters) account for 11.2% of the `static_assert`s.
In these cases, the `Ts` are typically not spelled out explicitly, e.g.
`static_assert(std::is_same<SomeT::TypeT, typename SomeDependentT::value_type>::value, "message");`
The diagnostic when the assert fails is typically not very useful, e.g.
`static_assert failed due to requirement 'std::is_same<SomeT::TypeT, typename SomeDependentT::value_type>::value' "message"`
This change makes the diagnostic spell out the types explicitly , e.g.
`static_assert failed due to requirement 'std::is_same<int, float>::value' "message"`
See tests for more examples.
After this is submitted, I intend to handle
`static_assert(!std::some_type_trait<Ts...>::value, "msg")`,
which is another 6.6% of static_asserts.
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D54903
llvm-svn: 348239
When the global new and delete operators aren't declared, Clang
provides and implicit declaration, but this declaration currently
always uses the default visibility. This is a problem when the
C++ library itself is being built with non-default visibility because
the implicit declaration will force the new and delete operators to
have the default visibility unlike the rest of the library.
The existing workaround is to use assembly to enforce the visiblity:
https://fuchsia.googlesource.com/zircon/+/master/system/ulib/zxcpp/new.cpp#108
but that solution is not always available, e.g. in the case of of
libFuzzer which is using an internal version of libc++ that's also built
with -fvisibility=hidden where the existing behavior is causing issues.
This change introduces a new option -fvisibility-global-new-delete-hidden
which makes the implicit declaration of the global new and delete
operators hidden.
Differential Revision: https://reviews.llvm.org/D53787
llvm-svn: 348234
Craig Topper