The first attempt, rL315614 was reverted because one libcxx
test broke, and i did not know at the time how to deal with it.
Summary:
Currently, clang only diagnoses completely out-of-range comparisons (e.g. `char` and constant `300`),
and comparisons of unsigned and `0`. But gcc also does diagnose the comparisons with the
`std::numeric_limits<>::max()` / `std::numeric_limits<>::min()` so to speak
Finally Fixes https://bugs.llvm.org/show_bug.cgi?id=34147
Continuation of https://reviews.llvm.org/D37565
Reviewers: rjmccall, rsmith, aaron.ballman
Reviewed By: rsmith
Subscribers: rtrieu, jroelofs, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D38101
llvm-svn: 315875
Summary:
Convert clang::LangAS to a strongly typed enum
Currently both clang AST address spaces and target specific address spaces
are represented as unsigned which can lead to subtle errors if the wrong
type is passed. It is especially confusing in the CodeGen files as it is
not possible to see what kind of address space should be passed to a
function without looking at the implementation.
I originally made this change for our LLVM fork for the CHERI architecture
where we make extensive use of address spaces to differentiate between
capabilities and pointers. When merging the upstream changes I usually
run into some test failures or runtime crashes because the wrong kind of
address space is passed to a function. By converting the LangAS enum to a
C++11 we can catch these errors at compile time. Additionally, it is now
obvious from the function signature which kind of address space it expects.
I found the following errors while writing this patch:
- ItaniumRecordLayoutBuilder::LayoutField was passing a clang AST address
space to TargetInfo::getPointer{Width,Align}()
- TypePrinter::printAttributedAfter() prints the numeric value of the
clang AST address space instead of the target address space.
However, this code is not used so I kept the current behaviour
- initializeForBlockHeader() in CGBlocks.cpp was passing
LangAS::opencl_generic to TargetInfo::getPointer{Width,Align}()
- CodeGenFunction::EmitBlockLiteral() was passing a AST address space to
TargetInfo::getPointerWidth()
- CGOpenMPRuntimeNVPTX::translateParameter() passed a target address space
to Qualifiers::addAddressSpace()
- CGOpenMPRuntimeNVPTX::getParameterAddress() was using
llvm::Type::getPointerTo() with a AST address space
- clang_getAddressSpace() returns either a LangAS or a target address
space. As this is exposed to C I have kept the current behaviour and
added a comment stating that it is probably not correct.
Other than this the patch should not cause any functional changes.
Reviewers: yaxunl, pcc, bader
Reviewed By: yaxunl, bader
Subscribers: jlebar, jholewinski, nhaehnle, Anastasia, cfe-commits
Differential Revision: https://reviews.llvm.org/D38816
llvm-svn: 315871
When using lld on macOS the current level of detection between ld and
ld64 forces us to rename lld to ld.
For ELF targets we have the ld.lld alias so for MACHO we should have
ld64.lld so we can use lld without replacing the system compiler.
This also solves the additional issue of cross compiling for MACHO
where renaming lld to ld with only target ELF.
This is the clang driver component change to use this new alias.
Reviewers: ruiu, rnk
Differential Revision: https://reviews.llvm.org/D38290
llvm-svn: 315867
This patch implements an extension to the preprocessor:
__VA_OPT__(contents) --> which expands into its contents if variadic arguments are supplied to the parent macro, or behaves as an empty token if none.
- Currently this feature is only enabled for C++2a (this could be enabled, with some careful tweaks, for other dialects with the appropriate extension or compatibility warnings)
- The patch was reviewed here: https://reviews.llvm.org/D35782 and asides from the above (and moving some of the definition and expansion recognition logic into the corresponding state machines), I believe I incorporated all of Richard's suggestions.
A few technicalities (most of which were clarified through private correspondence between rsmith, hubert and thomas) are worth mentioning. Given:
#define F(a,...) a #__VA_OPT__(a ## a) a ## __VA_OPT__(__VA_ARGS__)
- The call F(,) Does not supply any tokens for the variadic arguments and hence VA_OPT behaves as a placeholder.
- When expanding VA_OPT (for e.g. F(,1) token pasting occurs eagerly within its contents if the contents need to be stringified.
- A hash or a hashhash prior to VA_OPT does not inhibit expansion of arguments if they are the first token within VA_OPT.
- When a variadic argument is supplied, argument substitution occurs within the contents as does stringification - and these resulting tokens are inserted back into the macro expansions token stream just prior to the entire stream being rescanned and concatenated.
See wg21.link/P0306 for further details on the feature.
Acknowledgment: This patch would have been poorer if not for Richard Smith's usual thoughtful analysis and feedback.
llvm-svn: 315840
In OpenCL the kernel function and non-kernel function has different calling conventions.
For certain targets they have different argument ABIs. Also kernels have special function
attributes and metadata for runtime to launch them.
The blocks passed to enqueue_kernel is supposed to be executed as kernels. As such,
the block invoke function should be emitted as kernel with proper calling convention and
argument ABI.
This patch emits enqueued block as kernel. If a block is both called directly and passed
to enqueue_kernel, separate functions will be generated.
Differential Revision: https://reviews.llvm.org/D38134
llvm-svn: 315804
If the variable construction can be constant evaluated it doesn't have
side effects, so removing it is always safe. We only try to evaluate
variables that are unused, there should be no impact on compile time.
Differential Revision: https://reviews.llvm.org/D38678
llvm-svn: 315787
The function sanitizer only checks indirect calls through function
pointers. This excludes all non-static member functions (constructor
calls, calls through thunks, etc. all use a separate code path). Don't
emit function signatures for functions that won't be checked.
Apart from cutting down on code size, this should fix a regression on
Linux caused by r313096. For context, see the mailing list discussion:
r313096 - [ubsan] Function Sanitizer: Don't require writable text segments
Testing: check-clang, check-ubsan
Differential Revision: https://reviews.llvm.org/D38913
llvm-svn: 315786
It's possible for the code completion consumer to add new decls to the
current scope while lookup happens on it. Avoid this by making a copy
first.
Sadly I wasn't able to get a self-contained test case for this as it
requires code completion + precompiled preamble + the stars aligning to
deserialize at exactly the right time.
llvm-svn: 315772
In some cases the analyzer didn't expect an array-type variable to be
initialized with anything other than a string literal. The patch essentially
removes the assertion, and ensures relatively sane behavior.
There is a bigger problem with these initializers. Currently our memory model
(RegionStore) is being ordered to initialize the array with a region that
is assumed to be storing the initializer rvalue, and it guesses to copy
the contents of that region to the array variable. However, it would make
more sense for RegionStore to receive the correct initializer in the first
place. This problem isn't addressed with this patch.
rdar://problem/27248428
Differential Revision: https://reviews.llvm.org/D23963
llvm-svn: 315750
The checker used to crash when a mempcpy's length argument is symbolic. In this
case the cast from 'void *' to 'char *' failed because the respective
ElementRegion that represents cast is hard to add on top of the existing
ElementRegion that represents the offset to the last copied byte, while
preseving a sane memory region structure.
Additionally, a few test cases are added (to casts.c) which demonstrate problems
caused by existing sloppy work we do with multi-layer ElementRegions. If said
cast would be modeled properly in the future, these tests would need to be
taken into account.
Differential Revision: https://reviews.llvm.org/D38797
llvm-svn: 315742
It is not uncommon for the users to make their own wrappers around
CoreFoundation's CFRetain and CFRelease functions that are defensive
against null references. In such cases CFRetain is often incorrectly
marked as CF_RETURNS_RETAINED. Ignore said annotation and treat such
wrappers similarly to the regular CFRetain.
rdar://problem/31699502
Differential Revision: https://reviews.llvm.org/D38877
llvm-svn: 315736
Currently Clang uses default address space (0) to represent private address space for OpenCL
in AST. There are two issues with this:
Multiple address spaces including private address space cannot be diagnosed.
There is no mangling for default address space. For example, if private int* is emitted as
i32 addrspace(5)* in IR. It is supposed to be mangled as PUAS5i but it is mangled as
Pi instead.
This patch attempts to represent OpenCL private address space explicitly in AST. It adds
a new enum LangAS::opencl_private and adds it to the variable types which are implicitly
private:
automatic variables without address space qualifier
function parameter
pointee type without address space qualifier (OpenCL 1.2 and below)
Differential Revision: https://reviews.llvm.org/D35082
llvm-svn: 315668
This feature is not (yet) approved by the C++ committee, so this is liable to
be reverted or significantly modified based on committee feedback.
No functionality change intended for existing code (a new type must be defined
in namespace std to take advantage of this feature).
llvm-svn: 315662
The recommit fixes a UB bug that occurred only on a small number of bots.
Original message:
This commit adds initial support for refactoring options. One can now use
optional and required std::string options.
This commit also adds a NewNameOption for the local-rename refactoring action to
allow rename to work with custom names.
Differential Revision: https://reviews.llvm.org/D37856
llvm-svn: 315661
Fix PR32990 by effectively reverting r283063 and solving it a different
way.
We want to limit the hack to not replace equivalent available_externally
dtors specifically to libc++, which uses always_inline. It seems certain
versions of libc++ do not provide all the symbols that an explicit
template instantiation is expected to provide.
If we get to the code that forms a real alias, only *then* check if this
is available_externally, and do that by asking a better question, which
is "is this a declaration for the linker?", because *that's* what means
we can't form an alias to it.
As a follow-on simplification, remove the InEveryTU parameter. Its last
use guarded this code for forming aliases, but we should never form
aliases to declarations, regardless of what we know about every TU.
llvm-svn: 315656
overriding methods.
This should fix test case Analysis/retain-release.m that was failing on
the reverse iteration bot:
http://lab.llvm.org:8011/builders/reverse-iteration
The test used to fail because the loop in CheckObjCMethodOverrides would
merge attribute ns_returns_retained on methods while checking whether
the overriding methods were compatible. Since OverrideSearch::Overridden
is a SmallPtrSet and the order in which the elements of the set are
visited is non-deterministic, the test would fail when method 'clone' of
the protocol 'F18P' was visited before F18(Cat)'s method 'clone' was
visited.
llvm-svn: 315639
It seems that all of the other templated cases are handled correctly,
however the function template case was not correctly handled. This
patch recovers from this condition by setting the function to noexcept
after diagnosing. Previously it simply set NoexceptExpr to null,
which caused an Assert when this was evaluated during substitution.
Differential Revision:https://reviews.llvm.org/D38700
llvm-svn: 315638
Summary:
Currently, clang only diagnoses completely out-of-range comparisons (e.g. `char` and constant `300`),
and comparisons of unsigned and `0`. But gcc also does diagnose the comparisons with the
`std::numeric_limits<>::max()` / `std::numeric_limits<>::min()` so to speak
Finally Fixes https://bugs.llvm.org/show_bug.cgi?id=34147
Continuation of https://reviews.llvm.org/D37565
Reviewers: rjmccall, rsmith, aaron.ballman
Reviewed By: rsmith
Subscribers: rtrieu, jroelofs, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D38101
llvm-svn: 315614
reduction.
If the reduction is an array or an array section and reduction operation
is declare reduction without initializer, it may lead to crash.
llvm-svn: 315611
in C.
If we try to get the lvalue for thread_id variables in inlined regions,
we did not use the correct version of function. Fixed this bug by adding
overrided version of the function getThreadIDVariableLValue for inlined
regions.
llvm-svn: 315578
This patch enables explicit generation of TBAA information in all
cases where LValue base info is propagated or constructed in
non-trivial ways. Eventually, we will consider each of these
cases to make sure the TBAA information is correct and not too
conservative. For now, we just fall back to generating TBAA info
from the access type.
This patch should not bring in any functional changes.
This is part of D38126 reworked to be a separate patch to
simplify review.
Differential Revision: https://reviews.llvm.org/D38733
llvm-svn: 315575
This reverts commit 4e4ee1c507e2707bb3c208e1e1b6551c3015cbf5.
This is failing due to some code that isn't built on MSVC
so I didn't catch. Not immediately obvious how to fix this
at first glance, so I'm reverting for now.
llvm-svn: 315536
There's a lot of misuse of Twine scattered around LLVM. This
ranges in severity from benign (returning a Twine from a function
by value that is just a string literal) to pretty sketchy (storing
a Twine by value in a class). While there are some uses for
copying Twines, most of the very compelling ones are confined
to the Twine class implementation itself, and other uses are
either dubious or easily worked around.
This patch makes Twine's copy constructor private, and fixes up
all callsites.
Differential Revision: https://reviews.llvm.org/D38767
llvm-svn: 315530
Apple's API verification tool (tapi) checks that the symbols exported
from a program match a whitelist. When the program uses the profile
runtime, some additional symbols which are typically not part of the
regular whitelist must be exported.
If we're using symbol export directives along with the profile runtime
on Darwin, the driver needs to export the additional symbols to avoid
verification failures.
rdar://problem/30067753
llvm-svn: 315518
Summary: According to Intel docs this should take void const *. We had char*. The lack of const is the main issue.
Reviewers: RKSimon, zvi, igorb
Reviewed By: igorb
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38782
llvm-svn: 315470
If both taskloop and task directives are used at the same time in one
program, we may ran into the situation when the particular type for task
directive is reused for taskloop directives. Patch fixes this problem.
llvm-svn: 315464
Treat 'f()' as 'f(void)' rather than a function w/o a prototype.
Reviewers: Anastasia, yaxunl
Reviewed By: Anastasia, yaxunl
Subscribers: cfe-commits, echuraev, chapuni
Differential Revision: https://reviews.llvm.org/D33681
Re-apply revision 306653.
llvm-svn: 315453
This is breaking a build of https://github.com/abseil/abseil-cpp and so
likely not really NFC. Also reverted subsequent r314956/7.
I'll forward reproduction instructions to Richard.
llvm-svn: 315439
This change adds a new function, CodeGen::getFieldNumber, that
enables a user of clang's code generation to get the field number
in a generated LLVM IR struct that corresponds to a particular field
in a C struct.
It is important to expose this information in Clang's code generation
interface because there is no reasonable way for users of Clang's code
generation to get this information. In particular:
LLVM struct types do not include field names.
Clang adds a non-trivial amount of logic to the code generation of LLVM IR types for structs, in particular to handle padding and bit fields.
Patch by Michael Ferguson!
Differential Revision: https://reviews.llvm.org/D38473
llvm-svn: 315392
When declaring an entity in the "purview" of a module, it's never a
redeclaration of an entity in the purview of a default module or in no module
("in the global module"). Don't consider those other declarations as possible
redeclaration targets if they're not visible, and reject any cases where we
pick a prior visible declaration that violates this rule.
This reinstates r315251 and r315256, reverted in r315309 and r315308
respectively, tweaked to avoid triggering a linkage calculation when declaring
implicit special members (this exposed our pre-existing issue with typedef
names for linkage changing the linkage of types whose linkage has already been
computed and cached in more cases). A testcase for that regression has been
added in r315366.
llvm-svn: 315379
This allows clients to avoid an unnecessary fs::status() call on each
directory entry. Because the information returned by FindFirstFileEx
is a subset of the information returned by a regular status() call,
I needed to extract a base class from file_status that contains only
that information.
On my machine, this reduces the time required to enumerate a ThinLTO
cache directory containing 520k files from almost 4 minutes to less
than 2 seconds.
Differential Revision: https://reviews.llvm.org/D38716
llvm-svn: 315378
Usually compare expression should return i1 type, so EmitScalarConversion is called before return
return EmitScalarConversion(Result, CGF.getContext().BoolTy, E->getType(), E->getExprLoc());
But when ppc intrinsic is called to compare vectors, the ppc intrinsic can return i32 even E->getType() is BoolTy, in this case EmitScalarConversion does nothing, an i32 type result is returned and causes crash later.
This patch detects this case and truncates the result before return.
Differential Revision: https://reviews.llvm.org/D38656
llvm-svn: 315358
This is a re-commit of r315025, but making sure to only apply this to
specializations of class template member functions; i.e. not when the function
itself is a template.
llvm-svn: 315330
If a method is resetting the state of an object that was moved from, it should
be safe to use this object again. However if the method was defined in a parent
class, but used in a child class, the reset didn't happen from the checker's
perspective.
Differential Revision: https://reviews.llvm.org/D31538
llvm-svn: 315301
This method injects additional information into program state dumps,
describing which objects have been moved from.
Differential Revision: https://reviews.llvm.org/D31541
llvm-svn: 315300
This method injects additional information into program state dumps,
describing states of mutexes tracked by the checker.
Differential Revision: https://reviews.llvm.org/D37805
llvm-svn: 315298
Besides obvious code simplification, avoiding explicit creation
of LValueBaseInfo objects makes it easier to make TBAA
information to be part of such objects.
This is part of D38126 reworked to be a separate patch to
simplify review.
Differential Revision: https://reviews.llvm.org/D38695
llvm-svn: 315289
ARCReclaimReturnedObject cast.
This is a follow-up to r314370.
Rather than throwing away the enclosing parentheses, this commit walks
down the expression until an ARCReclaimReturnedObject cast is found and
removes just the cast, preserving the syntactic sugar expressions
(parens and casts) that were visited up to that point.
rdar://problem/34705720
Differential Revision: https://reviews.llvm.org/D38659
llvm-svn: 315261
This works around a language issue where adding a typedef name for linkage
purposes changes the linkage of an already-defined class after it becomes
complete.
llvm-svn: 315256
When declaring an entity in the "purview" of a module, it's never a
redeclaration of an entity in the purview of a default module or in no module
("in the global module"). Don't consider those other declarations as possible
redeclaration targets if they're not visible, and reject any cases where we
pick a prior visible declaration that violates this rule.
llvm-svn: 315251
Summary:
It was previsouly set only in ASTUnit, but it should be set for all client of
PrecompiledPreamble.
Reviewers: erikjv, bkramer, klimek
Reviewed By: bkramer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D38617
llvm-svn: 315212
Move the logic for determining the `wchar_t` type information into the
driver. Rather than passing the single bit of information of
`-fshort-wchar` indicate to the frontend the desired type of `wchar_t`
through a new `-cc1` option of `-fwchar-type` and indicate the
signedness through `-f{,no-}signed-wchar`. This replicates the current
logic which was spread throughout Basic into the
`RenderCharacterOptions`.
Most of the changes to the tests are to ensure that the frontend uses
the correct type. Add a new test set under `test/Driver/wchar_t.c` to
ensure that we calculate the proper types for the various cases.
llvm-svn: 315126
Summary:
This raises our default past 1900, which controls whether char16_t is a
builtin type or not.
Implements PR34243
Reviewers: hans
Subscribers: STL_MSFT, rsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D38646
llvm-svn: 315107
This was done for CUDA functions in r261779, and for the same
reason this also needs to be done for OpenCL. An arbitrary
function could have a barrier() call in it, which in turn
requires the calling function to be convergent.
llvm-svn: 315094
This commit adds initial support for refactoring options. One can now use
optional and required std::string options.
This commit also adds a NewNameOption for the local-rename refactoring action to
allow rename to work with custom names.
Differential Revision: https://reviews.llvm.org/D37856
llvm-svn: 315087
Previously we may erroneously try to capture locally declared static
variables, which will lead to crash for target-based constructs.
Patch fixes this problem.
llvm-svn: 315076
The Cpu Init functionality is required for the target
attribute, so this patch simply splits it out into its own
function, exactly like CpuIs and CpuSupports.
llvm-svn: 315075
In C++11 variable to global variables are considered as constant
expressions and these variables are not captured in the outlined
regions. Patch allows capturing of such variables in the OpenMP regions.
llvm-svn: 315074
This patch is an attempt to clarify and simplify generation and
propagation of TBAA information. The idea is to pack all values
that describe a memory access, namely, base type, access type and
offset, into a single structure. This is supposed to make further
changes, such as adding support for unions and array members,
easier to prepare and review.
DecorateInstructionWithTBAA() is no more responsible for
converting types to tags. These implicit conversions not only
complicate reading the code, but also suggest assigning scalar
access tags while we generally prefer full-size struct-path tags.
TBAAPathTag is replaced with TBAAAccessInfo; the latter is now
the type of the keys of the cache map that translates access
descriptors to metadata nodes.
Fixed a bug with writing to a wrong map in
getTBAABaseTypeMetadata() (former getTBAAStructTypeInfo()).
We now check for valid base access types every time we
dereference a field. The original code only checks the top-level
base type. See isValidBaseType() / isTBAAPathStruct() calls.
Some entities have been renamed to sound more adequate and less
confusing/misleading in presence of path-aware TBAA information.
Now we do not lookup twice for the same cache entry in
getAccessTagInfo().
Refined relevant comments and descriptions.
Differential Revision: https://reviews.llvm.org/D37826
llvm-svn: 315048
code size.
Currently clang expands a call to __builtin_os_log_format into a long
sequence of instructions at the call site, causing code size to
increase in some cases.
This commit attempts to reduce code size by emitting a helper function
that can be shared by calls to __builtin_os_log_format with similar
formats and arguments. The helper function has linkonce_odr linkage to
enable the linker to merge identical functions across translation units.
Attribute 'noinline' is attached to the helper function at -Oz so that
the inliner doesn't inline functions that can potentially be merged.
This commit also fixes a bug where the generated IR writes past the end
of the buffer when "%m" is the last specifier appearing in the format
string passed to __builtin_os_log_format.
Original patch by Duncan Exon Smith.
rdar://problem/34065973
rdar://problem/34196543
Differential Revision: https://reviews.llvm.org/D38606
llvm-svn: 315045
Summary:
* Rename -shared-libasan to -shared-libsan, keeping the old name as alias.
* Add -static-libsan for targets that default to shared.
* Remove an Android special case. It is now possible (but untested) to use static compiler-rt libraries there.
* Support libclang_rt.ubsan_standalone as a shared library.
Unlike GCC, this change applies -shared-libsan / -static-libsan to all sanitizers.
I don't see a point in multiple flags like -shared-libubsan, considering that most sanitizers
are not compatible with each other, and each link has basically a single shared/static choice.
Reviewers: vitalybuka, kcc, rsmith
Subscribers: srhines, cfe-commits
Differential Revision: https://reviews.llvm.org/D38525
llvm-svn: 315015
If we resolve an overloaded operator call to a specific function during
template definition, don't perform ADL during template instantiation.
Doing so finds overloads that we're not supposed to find.
llvm-svn: 315005
If the `defaultmap(tofrom:scalar)` clause is specified, the scalars must
be mapped with 'tofrom' modifiers, otherwise they must be captured as
firstprivates.
llvm-svn: 314995
This patch makes it possible to produce access tags in a uniform
manner regardless whether the resulting tag will be a scalar or a
struct-path one. getAccessTagInfo() now takes care of the actual
translation of access descriptors to tags and can handle all
kinds of accesses. Facilities that specific to scalar accesses
are eliminated.
Some more details:
* DecorateInstructionWithTBAA() is not responsible for conversion
of types to access tags anymore. Instead, it takes an access
descriptor (TBAAAccessInfo) and generates corresponding access
tag from it.
* getTBAAInfoForVTablePtr() reworked to
getTBAAVTablePtrAccessInfo() that now returns the
virtual-pointer access descriptor and not the virtual-point
type metadata.
* Added function getTBAAMayAliasAccessInfo() that returns the
descriptor for may-alias accesses.
* getTBAAStructTagInfo() renamed to getTBAAAccessTagInfo() as now
it is the only way to generate access tag by a given access
descriptor. It is capable of producing both scalar and
struct-path tags, depending on options and availability of the
base access type. getTBAAScalarTagInfo() and its cache
ScalarTagMetadataCache are eliminated.
* Now that we do not need to care about whether the resulting
access tag should be a scalar or struct-path one,
getTBAAStructTypeInfo() is renamed to getBaseTypeInfo().
* Added function getTBAAAccessInfo() that constructs access
descriptor by a given QualType access type.
This is part of D37826 reworked to be a separate patch to
simplify review.
Differential Revision: https://reviews.llvm.org/D38503
llvm-svn: 314979
This patch makes it possible to produce access tags in a uniform
manner regardless whether the resulting tag will be a scalar or a
struct-path one. getAccessTagInfo() now takes care of the actual
translation of access descriptors to tags and can handle all
kinds of accesses. Facilities that specific to scalar accesses
are eliminated.
Some more details:
* DecorateInstructionWithTBAA() is not responsible for conversion
of types to access tags anymore. Instead, it takes an access
descriptor (TBAAAccessInfo) and generates corresponding access
tag from it.
* getTBAAInfoForVTablePtr() reworked to
getTBAAVTablePtrAccessInfo() that now returns the
virtual-pointer access descriptor and not the virtual-point
type metadata.
* Added function getTBAAMayAliasAccessInfo() that returns the
descriptor for may-alias accesses.
* getTBAAStructTagInfo() renamed to getTBAAAccessTagInfo() as now
it is the only way to generate access tag by a given access
descriptor. It is capable of producing both scalar and
struct-path tags, depending on options and availability of the
base access type. getTBAAScalarTagInfo() and its cache
ScalarTagMetadataCache are eliminated.
* Now that we do not need to care about whether the resulting
access tag should be a scalar or struct-path one,
getTBAAStructTypeInfo() is renamed to getBaseTypeInfo().
* Added function getTBAAAccessInfo() that constructs access
descriptor by a given QualType access type.
This is part of D37826 reworked to be a separate patch to
simplify review.
Differential Revision: https://reviews.llvm.org/D38503
llvm-svn: 314977
The analyzer now realizes that C++ std::initializer_list objects and
Objective-C boxed structure/array/dictionary expressions can potentially
maintain a reference to the objects that were put into them. This avoids
false memory leak posivites and a few other issues.
This is a conservative behavior; for now, we do not model what actually happens
to the objects after being passed into such initializer lists.
rdar://problem/32918288
Differential Revision: https://reviews.llvm.org/D35216
llvm-svn: 314975
Passes 'new-pass-manager' option to the linker plugin when the new pass
manager is enabled.
Patch by Graham Yiu.
Differential Revision: https://reviews.llvm.org/D38517
llvm-svn: 314964
In its place, track on the canonical function declaration whether there is a
declaration with a body (and if so, which one). This brings function definition
handling in line with what we do in all other contexts, and is necessary to
allow us to merge declarations within multiple definitions of the same function
(eg, PR33924).
No functionality change intended.
llvm-svn: 314955
As reported on cfe-commits, r314262 resulted in tentatively-defined
variables not being excluded for the warning.
Patch By: Elizabeth Andrews
llvm-svn: 314939
Currently block is translated to a structure equivalent to
struct Block {
void *isa;
int flags;
int reserved;
void *invoke;
void *descriptor;
};
Except invoke, which is the pointer to the block invoke function,
all other fields are useless for OpenCL, which clutter the IR and
also waste memory since the block struct is passed to the block
invoke function as argument.
On the other hand, the size and alignment of the block struct is
not stored in the struct, which causes difficulty to implement
__enqueue_kernel as library function, since the library function
needs to know the size and alignment of the argument which needs
to be passed to the kernel.
This patch removes the useless fields from the block struct and adds
size and align fields. The equivalent block struct will become
struct Block {
int size;
int align;
generic void *invoke;
/* custom fields */
};
It also changes the pointer to the invoke function to be
a generic pointer since the address space of a function
may not be private on certain targets.
Differential Revision: https://reviews.llvm.org/D37822
llvm-svn: 314932
In ProgramState::getSVal(Location, Type) API which dereferences a pointer value,
when the optional Type parameter is not supplied and the Location is not typed,
type should have been guessed on a best-effort basis by inspecting the Location
more deeply. However, this never worked; the auto-detected type was instead
a pointer type to the correct type.
Fixed the issue and added various test cases to demonstrate which parts of the
analyzer were affected (uninitialized pointer argument checker, C++ trivial copy
modeling, Google test API modeling checker).
Additionally, autodetected void types are automatically replaced with char,
in order to simplify checker APIs. Which means that if the location is a void
pointer, getSVal() would read the first byte through this pointer
and return its symbolic value.
Fixes pr34305.
Differential Revision: https://reviews.llvm.org/D38358
llvm-svn: 314910
https://reviews.llvm.org/D38371
This patch implements codegen for the combined 'teams distribute" OpenMP pragma and adds regression tests for all its clauses.
llvm-svn: 314905
The recent fix in D38258 was wrong: getAuxTriple() only returns
non-null values for the CUDA toolchain. That is why the now added
test for PPC and X86 failed.
Differential Revision: https://reviews.llvm.org/D38372
llvm-svn: 314902
We were injecting the function into the wrong semantic context, resulting in it
failing to be registered as a global for redeclaration lookup. As a
consequence, we accepted invalid code since r310616.
Fixing that resulted in the "out-of-scope declaration" diagnostic firing a lot
more often. It turned out that warning codepath was non-conforming, because it
did not cause us to inject the implicitly-declared function into the enclosing
block scope. We now only warn if the type of the out-of-scope declaration
doesn't match the type of an implicitly-declared function; in all other cases,
we produce the normal warning for an implicitly-declared function.
llvm-svn: 314871
Fixes the test failure: temporary is now bound to std::string, tests
fully pass on Linux.
This reverts commit b36ee0924038e1d95ea74230c62d46e05f80587e.
llvm-svn: 314859
In C++, such initialization of std::array<T, N> types is guaranteed to work by
the standard, is completely idiomatic, and the "suggested" alternative from
Clang was technically invalid.
llvm-svn: 314838
declaration.
Patch allows using of the `#pragma omp declare target`| `#pragma omp end
declare target` directives inside the structures if we need to mark as
declare target only some static members.
llvm-svn: 314833
Only assume that IOBSDNameMatching and friends increment a reference counter
if their return type is a CFMutableDictionaryRef.
Differential Revision: https://reviews.llvm.org/D38487
llvm-svn: 314820
Currently clang allows the following code
int a;
int b = (const int) a;
However it does not the following code
int4 a;
int4 b = (const int4) a;
This is because Clang compares the qualified types instead of unqualified types for vector type casting, which causes the inconsistency.
This patch fixes that.
Differential Revision: https://reviews.llvm.org/D38463
llvm-svn: 314802
This patch fixes clang to propagate complete TBAA information for
atomic accesses and not just the final access types. Prepared
against D38456 and requires it to be committed first.
This is part of D37826 reworked to be a separate patch to
simplify review.
Differential Revision: https://reviews.llvm.org/D38460
llvm-svn: 314784
With this patch we implement a concept of TBAA access descriptors
that are capable of representing both scalar and struct-path
accesses in a generic way.
This is part of D37826 reworked to be a separate patch to
simplify review.
Differential Revision: https://reviews.llvm.org/D38456
llvm-svn: 314780
Don't emit alignment checks which the IR constant folder throws away.
I've tested this out on X86FastISel.cpp. While this doesn't decrease
end-to-end compile-time significantly, it results in 122 fewer type
checks (1% reduction) overall, without adding any real complexity.
Differential Revision: https://reviews.llvm.org/D37544
llvm-svn: 314752
- it made the bots v angry!
I'm not exactly sure why the assertion doesn't hold - if anyone has any insight - would appreciate it.
Thanks!
llvm-svn: 314748
In passing:
- change the name of the function to pasteTokens c/w coding standards
- rename CurToken to CurTokenIdx (since it is not the token, but the index)
- add doxygen comments to document some of pasteTokens' functionality
- use parameter names different from the data member names.
This will be useful for implementing __VA_OPT__ (https://reviews.llvm.org/D35782#inline-322587)
llvm-svn: 314747
Roman Lebedev