Tests introduced in r329780 was disabled in r342317 because these tests
were accidentally testing dump infrastructure, when all they cared about was
how symbols relate to each other. So when dump infrastructure changed,
tests became annoying to maintain.
Add a new feature to ExprInspection: clang_analyzer_denote() and
clang_analyzer_explain(). The former adds a notation to a symbol, the latter
expresses another symbol in terms of previously denoted symbols.
It's currently a bit wonky - doesn't print parentheses and only supports
denoting atomic symbols. But it's even more readable that way.
Differential Revision: https://reviews.llvm.org/D52133
llvm-svn: 343048
PPC64BE bots use % instead of @ for directives like progbits. Since CFString tests also
check asm output, they fail on the following:
cfstring3.c:44:19: error: CHECK-ASM-ELF: expected string not found in input
// CHECK-ASM-ELF: .section cfstring,"aw",@progbits
<stdin>:30:2: note: possible intended match here
.section cfstring,"aw",%progbits
Updating that check with a {{[@%]}}progbits regex to make those bots happy.
llvm-svn: 343044
Relanding rL342883 with more fragmented tests to test ELF-specific
section emission separately from broad-scope CFString tests. Now this
tests the following separately
1). CoreFoundation builds and linkage for ELF while building it.
2). CFString ELF section emission outside CF in assembly output.
3). Broad scope `cfstring3.c` tests which cover all object formats at
bitcode level and assembly level (including ELF).
This fixes non-bridged CoreFoundation builds on ELF targets
that use -fconstant-cfstrings. The original changes from differential
for a similar patch to PE/COFF (https://reviews.llvm.org/D44491) did not
check for an edge case where the global could be a constant which surfaced
as an issue when building for ELF because of different linkage semantics.
This patch addresses several issues with crashes related to CF builds on ELF
as well as improves data layout by ensuring string literals that back
the actual CFConstStrings end up in .rodata in line with Mach-O.
Change itself tested with CoreFoundation on Linux x86_64 but should be valid
for BSD-like systems as well that use ELF as the native object format.
Differential Revision: https://reviews.llvm.org/D52344
llvm-svn: 343038
Combine the two constructor overrides into a single ArrayRef constructor
to allow easier brace initializations and simplify how the respective field
is used internally.
Differential Revision: https://reviews.llvm.org/D51390
llvm-svn: 343037
When a checker maintains a program state trait that isn't a simple list/set/map, but is a combination of multiple lists/sets/maps (eg., a multimap - which may be implemented as a map from something to set of something), ProgramStateManager only contains the factory for the trait itself. All auxiliary lists/sets/maps need a factory to be provided by the checker, which is annoying.
So far two checkers wanted a multimap, and both decided to trick the
ProgramStateManager into keeping the auxiliary factory within itself
by pretending that it's some sort of trait they're interested in,
but then never using this trait but only using the factory.
Make this trick legal. Define a convenient macro.
One thing that becomes apparent once all pieces are put together is that
these two checkers are in fact using the same factory, because the type that
identifies it, ImmutableMap<const MemRegion *, ImmutableSet<SymbolRef>>,
is the same. This situation is different from two checkers registering similar
primitive traits.
Differential Revision: https://reviews.llvm.org/D51388
llvm-svn: 343035
types."
It reverts commit r342991 + several other commits intended to fix the
tests. Still have some failed tests, need to investigate it.
llvm-svn: 343002
clang-offload-bundler should not be invoked with the unbundling action
when the input file type does not match the action type. For example,
.so files should be unbundled during linking phase and should be linked
only with the host code.
llvm-svn: 342991
Summary:
Making X[8-15,18] registers call-saved is used to support
CONFIG_ARM64_LSE_ATOMICS in Linux kernel.
Signed-off-by: Tri Vo <trong@android.com>
Reviewers: srhines, nickdesaulniers, javed.absar
Reviewed By: nickdesaulniers
Subscribers: kristof.beyls, jfb, cfe-commits
Differential Revision: https://reviews.llvm.org/D52399
llvm-svn: 342990
This provides better help text in "clang-cl /?".
Also it cleans things up a bit: previously "/Od" could be handled either
as a separate flag aliased to "-O0", or by the main optimization flag
processing in TranslateOptArg. With this patch, all the flags get
aliased back to /O so they're handled by TranslateOptArg.
Thanks to Nico for the idea!
Differential revision: https://reviews.llvm.org/D52266
llvm-svn: 342977
Summary:
This is useful when derived file systems want to override some calls
and still proxy other calls.
Reviewers: ilya-biryukov, sammccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D52462
llvm-svn: 342976
Replace the pair std::pair<const NamedDecl *, unsigned> where the
unsigned represents an LVComputationKind by a PointerIntPair.
This saves a pointer per entry in the map LinkageComputer::CachedLinkageInfo.
Differential Revision: https://reviews.llvm.org/D52268
Reviewed by: rjmccall, george.burgess.iv, erichkeane
llvm-svn: 342973
This change allows for zero assignment and comparison of queue_t
type variables, and extends null_queue.cl to test this.
Patch by Alistair Davies.
Differential Revision: https://reviews.llvm.org/D51727
llvm-svn: 342968
When embedding bitcode, only a subset of the arguments should be recorded into
the bitcode compilation commandline. The frontend job is split into two jobs,
one which will generate the bitcode. Ensure that the arguments for the
compilation to bitcode is properly stripped so that the embedded arguments are
the permitted subset.
llvm-svn: 342929
for loop if both members exist.
This resolves a DR whereby an errant 'begin' or 'end' member in a base
class could result in a derived class not being usable as a range with
non-member 'begin' and 'end'.
llvm-svn: 342925
This patch is a band-aid. A proper solution would be too change
trackNullOrUndefValue to only try to dereference the pointer when it is
relevant to the problem.
Differential Revision: https://reviews.llvm.org/D52435
llvm-svn: 342920
Added
__builtin_vsx_scalar_extract_expq
__builtin_vsx_scalar_insert_exp_qp
Builtins should behave the same way as in GCC.
Differential Revision: https://reviews.llvm.org/D48184
llvm-svn: 342911
Discussed on cfe-commits (Week-of-Mon-20180820), this change leads to
the generation of invalid IR for OpenCL without giving an error.
Therefore, the conclusion was to revert.
llvm-svn: 342885
[Clang][CodeGen][ObjC]: Fix non-bridged CoreFoundation builds on ELF targets
that use `-fconstant-cfstrings`. The original changes from differential
for a similar patch to PE/COFF (https://reviews.llvm.org/D44491) did not
check for an edge case where the global could be a constant which surfaced
as an issue when building for ELF because of different linkage semantics.
This patch addresses several issues with crashes related to CF builds on ELF
as well as improves data layout by ensuring string literals that back
the actual CFConstStrings end up in .rodata in line with Mach-O.
Change itself tested with CoreFoundation on Linux x86_64 but should be valid
for BSD-like systems as well that use ELF as the native object format.
Differential Revision: https://reviews.llvm.org/D52344
llvm-svn: 342883
Armv8.4-A adds a few FP16 instructions that can optionally be implemented
in CPUs of Armv8.2-A and above.
This patch adds a feature to clang to permit selection of these
instructions. This interacts with the +fp16 option as follows:
Prior to Armv8.4-A:
*) +fp16fml implies +fp16
*) +nofp16 implies +nofp16fml
From Armv8.4-A:
*) The above conditions apply, additionally: +fp16 implies +fp16fml
Patch by Bernard Ogden.
Differential Revision: https://reviews.llvm.org/D50229
llvm-svn: 342862
Currently, attributes from previous declarations ('inherited attributes')
are added to the end of a declaration's list of attributes. Before
r338800, the attribute list was in reverse. r338800 changed the order
of non-inherited (parsed from the current declaration) attributes, but
inherited attributes are still appended to the end of the list.
This patch appends inherited attributes after other inherited
attributes, but before any non-inherited attribute. This is to make the
order of attributes in the AST correspond to the order in the source
code.
Differential Revision: https://reviews.llvm.org/D50214
llvm-svn: 342861
This is a workaround for PR39053 which was uncovered by D50652 when
the default attribute has been changed from internal_linkage to
always_inline.
Differential Revision: https://reviews.llvm.org/D52402
llvm-svn: 342833
Assuming strlcat is used with strlcpy we check as we can if the last argument does not equal os not larger than the buffer.
Advising the proper usual pattern.
Reviewers: george.karpenkov, NoQ, MaskRay
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D49722
llvm-svn: 342832
r341994 caused clangAnalysis to pull all of the AST matchers
library into clang. Due to inline key functions in the headers,
importing the AST matchers library gives a link dependency on the
AST matchers (and thus the AST), which clang should not
have.
This patch works around the issues by excluding the offending
libclangAnalysis header in the modulemap.
llvm-svn: 342827
aarch64 testing is broken because "medium" is not a valid
code-model on aarch64, and codemodels.c tests that. This fixes
that problem by adding "-triple x86_64-unknown-linux-gnu" to the
test with "-mcode-model moedium".
llvm-svn: 342812
Objects are determined to be smart pointers if they have both a star and arrow
operator. Some implementations of smart pointers have these overloaded
operators in a base class, while the check only searched the derived class.
This fix will also look for the operators in the base class.
llvm-svn: 342794
This can be used to detect whether the code is being built with UBSan using
the __has_feature(undefined_behavior_sanitizer) predicate.
Differential Revision: https://reviews.llvm.org/D52386
llvm-svn: 342793
Not used productively, so no observable functional change.
Note that printSCFG doesn't yet work reliably, it seems to crash
sometimes.
llvm-svn: 342790
A recent commit I made broke aarch64 testing, because "kernel"
apparently is not a valid code-model on aarch64, and one of my tests
tested that. This fixes the problem (hopefully) by adding "-triple
x86_64-unknown-linux-gnu" to the test build with "-mcodel-model
kernel".
Differential Revision: https://reviews.llvm.org/D52383
llvm-svn: 342789
Comparison functions used in sorting algorithms need to have strict weak
ordering. Remove the assert and allow comparisons on all lists.
llvm-svn: 342774
Modify the RetainCountChecker to perform state "adjustments" in
checkEndFunction, as performing work in PreStmt<ReturnStmt> does not
work with destructors.
The previous version made an implicit assumption that no code runs
after the return statement is executed.
rdar://43945028
Differential Revision: https://reviews.llvm.org/D52338
llvm-svn: 342770
If the non-sink report is generated at the exit node, it will be
suppressed by the current functionality in isInevitablySinking, as it
only checks the successors of the block, but not the block itself.
The bug shows up in RetainCountChecker checks.
Differential Revision: https://reviews.llvm.org/D52284
llvm-svn: 342766
Currently the code-model does not get saved in the module IR, so if a
code model is specified when compiling with LTO, it gets lost and is
not propagated properly to LTO. This patch does what is necessary in
the front end to pass the code-model to the module, so that the back
end can store it in the Module .
Differential Revision: https://reviews.llvm.org/D52323
llvm-svn: 342758
We need to consider all tokens that start with '>' when
we're checking for the end of an empty template argument list.
Differential Revision: https://reviews.llvm.org/D52321
llvm-svn: 342752
Previously clang considered function variants from both sides of
compilation and that resulted in picking up wrong deallocation function.
Differential Revision: https://reviews.llvm.org/D51808
llvm-svn: 342749
Some bots are complaining about missing parentheses in assertions added in
r342729: [AST] Various optimizations + refactoring in DeclarationName(Table)
llvm-svn: 342735
Summary:
This code was in CGDecl.cpp and really belongs in LLVM. It happened to have isBytewiseValue which served a very similar purpose but wasn't as powerful as clang's version. Remove the clang version, and augment isBytewiseValue to be as powerful so that clang does the same thing it used to.
LLVM part of this patch: D51751
Subscribers: dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D51752
llvm-svn: 342734
I originally added this enum to avoid including Basic/IdentifierTable.h
in AST/DeclBase.h. However I did not realise it is already included
transitively by AST/DeclarationName.h. Therefore remove this enum and
explicitly include Basic/IdentifierTable.h
llvm-svn: 342731
Introduce the following optimizations in DeclarationName(Table):
1. Store common kinds inline in DeclarationName instead of
DeclarationNameExtra. Currently the kind of C++ constructor, destructor,
conversion function and overloaded operator names is stored in
DeclarationNameExtra. Instead store it inline in DeclarationName.
To do this align IdentifierInfo, CXXSpecialName, DeclarationNameExtra
and CXXOperatorIdName to 8 bytes so that we can use the lower 3 bits of
DeclarationName::Ptr. This is already the case on 64 bits archs anyway.
This also allow us to remove DeclarationNameExtra from CXXSpecialName
and CXXOperatorIdName, which shave off a pointer from CXXSpecialName.
2. Synchronize the enumerations DeclarationName::NameKind,
DeclarationName::StoredNameKind and Selector::IdentifierInfoFlag.
This makes DeclarationName::getNameKind much more efficient since we can
replace the switch table by a single comparison and an addition.
3. Put the overloaded operator names inline in DeclarationNameTable to remove
an indirection. This increase the size of DeclarationNameTable a little
bit but this is not important since it is only used in ASTContext, and
never copied nor moved from. This also get rid of the last dynamic
allocation in DeclarationNameTable.
Altogether these optimizations cut the run time of parsing all of Boost by
about 0.8%. While we are at it, do the following NFC modifications:
1. Put the internal classes CXXSpecialName, CXXDeductionGuideNameExtra,
CXXOperatorIdName, CXXLiteralOperatorIdName and DeclarationNameExtra
in a namespace detail since these classes are only meant to be used by
DeclarationName and DeclarationNameTable. Make this more explicit by making
the members of these classes private and friending DeclarationName(Table).
2. Make DeclarationName::getFETokenInfo a non-template since every users are
using it to get a void *. It was supposed to be used with a type to avoid
a subsequent static_cast.
3. Change the internal functions DeclarationName::getAs* to castAs* since when
we use them we already know the correct kind. This has no external impact
since all of these are private.
Reviewed By: erichkeane, rjmccall
Differential Revision: https://reviews.llvm.org/D52267
llvm-svn: 342729
Current completion fix-its approach does not provide OtherOpBase for C code.
But we can easily proceed in this case taking the original Base type.
Differential Revision: https://reviews.llvm.org/D52261
llvm-svn: 342721
Summary:
Some lines have a hit counter where they should not have one.
Cleanup stuff is located to the last line of the body which is most of the time a '}'.
And Exception stuff is added at the beginning of a function and at the end (represented by '{' and '}').
So in such cases, the DebugLoc used in GCOVProfiling.cpp must be marked as not covered.
This patch is a followup of https://reviews.llvm.org/D49915.
Tests in projects/compiler_rt are fixed by: https://reviews.llvm.org/D49917
Reviewers: marco-c, davidxl
Reviewed By: marco-c
Subscribers: dblaikie, cfe-commits, sylvestre.ledru
Differential Revision: https://reviews.llvm.org/D49916
llvm-svn: 342717
Summary:
Add a test and ensure that we propagate the
-fxray-instrumentation-bundle flag from the driver invocation to the
-cc1 options.
Reviewers: mboerger, tejohnson
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D52342
llvm-svn: 342715
Removing on behalf of Jorge Moya. This test is broken on
Windows due to it actually being able to resolve the path. There
is an actual Windows-specific bug somewhere, but we already have
sufficient test coverage of this with a different test, so removing
this was the approach suggested by Jorge.
llvm-svn: 342693
include-likely-typo.c:3:10: error: '<empty_file_to_include.h>' file not found, did you mean 'empty_file_to_include.h'?
^~~~~~~~~~~~~~~~~~~~~~~~~~~
"empty_file_to_include.h"
1 error generated.
However, if a hint is not found, the error message will show only the trimmed name we use to look for a hint, so:
will result in:
include-leading-nonalpha-no-suggest.c:3:10: fatal error: 'non_existing_file_to_include.h' file not found
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
where the name reported after "fatal error:" doesn't match what the user wrote.
Patch by Jorge Gorbe!
Differential Revision: https://reviews.llvm.org/D52280
This change reports the original file name instead of the trimmed one when a suggestion is not found.
llvm-svn: 342667
Add a warning if a parameter with a named address space is passed
to a to_addr builtin.
For example:
int i;
to_private(&i); // generate warning as conversion from private to private is redundant.
Patch by Alistair Davies.
Differential Revision: https://reviews.llvm.org/D51411
llvm-svn: 342638
unsigned long long builtin_unpack_vector_int128 (vector int128_t, int);
vector int128_t builtin_pack_vector_int128 (unsigned long long, unsigned long long);
Builtins should behave the same way as in GCC.
Patch By: wuzish (Zixuan Wu)
Differential Revision: https://reviews.llvm.org/D52074
llvm-svn: 342614
Summary:
When thread safety annotations are used without capability arguments,
they are assumed to apply to `this` instead. So we warn when either
`this` doesn't exist, or the class is not a capability type.
This is based on earlier work by Josh Gao that was committed in r310403,
but reverted in r310698 because it didn't properly work in template
classes. See also D36237.
The solution is not to go via the QualType of `this`, which is then a
template type, hence the attributes are not known because it could be
specialized. Instead we look directly at the class in which we are
contained.
Additionally I grouped two of the warnings together. There are two
issues here: the existence of `this`, which requires us to be a
non-static member function, and the appropriate annotation on the class
we are contained in. So we don't distinguish between not being in a
class and being static, because in both cases we don't have `this`.
Fixes PR38399.
Reviewers: aaron.ballman, delesley, jmgao, rtrieu
Reviewed By: delesley
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D51901
llvm-svn: 342605
I had locally changed the test to add an explicit triple to figure out the issue
with the SCEI buildbots, and that hid the error. This now works with and
without the explicit triple.
llvm-svn: 342581
In the case that `win_t` is an `unsigned short` (e.g. on Windows), we would
previously incorrectly diagnose the conversion because we would immediately
promote the argument type from `wint_t` (aka `unsigned short`) to `int` before
checking if the type matched. This should repair the Windows hosted bots.
llvm-svn: 342565
Windows uses `unsigned short` for `wint_t`. Correct the type definition as
vended by the compiler. This type is defined in corecrt.h and is
unconditionally typedef'ed. cl does not have an equivalent to `__WINT_TYPE__`
which is why this was never detected.
llvm-svn: 342557
For function pointers, the FunctionDecl of the callee is unknown, so
getDirectCallee will return nullptr. We have to catch that case to avoid
crashing. We assume there is no attribute then.
llvm-svn: 342519
This adds a preprocessor callback for the `__has_include` and
`__has_include_next` directives.
Successful checking for the presence of a header should add it to the list of
header dependencies so this overrides the callback in the dependency scanner.
Patch by Pete Cooper with some additions by me.
rdar://problem/39545636
Differential Revision: https://reviews.llvm.org/D30882
llvm-svn: 342517
This special case was added in r264841, but the code breaks our
invariants by calling EmitTopLevelDecl without first creating a
HandlingTopLevelDeclRAII scope.
This fixes the PCH crash in https://crbug.com/884427. I was never able
to make a satisfactory reduction, unfortunately. I'm not very worried
about this regressing since this change makes the code simpler while
passing the existing test that shows we do emit dllexported friend
function definitions. Now we just defer their emission until the tag is
fully complete, which is generally good.
llvm-svn: 342516
Move the floating point argument handling into the RenderFloatingPointOptions
helper. This relocation just puts the floating point related options into a
single location.
llvm-svn: 342512
Summary:
As part of r342165, I rewrote the logic to check whether
-fno-omit-frame-pointer was passed after a -fomit-frame-pointer
argument. This CL switches that logic to use the consolidated
shouldUseFramePointer() function. This fixes a potential issue where -pg
gets used with -fomit-frame-pointer on a platform that must always retain
frame pointers.
Reviewers: dblaikie
Reviewed By: dblaikie
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D52191
llvm-svn: 342501
Artem Dergachev